Posted by tgeller on November 24, 2010 at 12:59am
Could maintainers (et al.) post their current plans for Drupal 7 versions of mapping solutions? I haven't seen anything in drupal.org/project/modules yet. Thanks!
Could maintainers (et al.) post their current plans for Drupal 7 versions of mapping solutions? I haven't seen anything in drupal.org/project/modules yet. Thanks!
Comments
Openlayers, see
Openlayers, see http://drupal.org/node/743856
--
zzolo
The OpenLayers port has
The OpenLayers port has proceeded faster than originally expected. However, the surrounding infrastructure is still extremely buggy, and the way that Drupal 7 handles fields and, well, everything else, makes it almost a non-starter for serious mapping applications.
What's wrong with how Drupal 7 handles fields?
That's a very intriguing statement. Could you clarify?
Tom Geller * Oberlin * San Francisco * TomGeller.com
Author/Presenter, Drupal video series at lynda.com
Creator of materials for Drupal-focused companies
Well, it seems like there are
Well, it seems like there are a few more in-depth analyses of Drupal 7's performance which would do a way better job than I could here. Currently, the most gamestopping problem is that Views in Drupal 7 doesn't support relationships with custom fields - something that prevents OpenLayers WKT from working on a high level. And when relations are implemented, they'll require several more queries per-row than in Drupal 6. Given that OpenLayers data displays often show at least 100 points, and some people are using them to display many more, adding a map to a page will slow it down significantly.
For cached sites, this doesn't matter that much but interesting sites tend not to be that cacheable.
There's also the problem that the entity framework is written so that there's no way of loading specific fields from an entity - only the entire entity. Given that map views tend to display subsets of data - title, lat/lon, short description, there's going to be significant and unnecessary loading of data from the database without reason. The field system, and the views architecture, which was essentially avoided in Drupal 6 (see
openlayers_views_style_data.inc), is less avoidable but no more flexible in Drupal 7, leading to code that has to struggle against the tides to produce non-HTML dual (rendered and unrendered) output.There are a handful of improvements in Drupal 7 which have improved the code of the module: a custom implementation of vertical tabs could be replaced with vertical tabs in core (although vertical tabs should probably have been a contrib module). The DB API was able to clean up a few CRUD functions (although these should actually just be encapsulated in the ctools exportables ui anyway).
You could easily overcome a
You could easily overcome a lot of what you have said via custom views handlers / relationship handlers. Out of the box not very helpful though.
Congratulations on the port...but D7?
G'Day tmcw:
I've just been nibbling at the edges of D7, but had great hopes for it with some upcoming map-centric projects. I respect your insights: can you dot point a couple of specific troublesomes you've encountered in D7?
Thanks heaps!