The OpenLayers JS library is pretty big at 700K. OpenLayers documentation says the whole library is best for development and that we should use a custom build of OpenLayers that includes only the parts of the library we need for our site.

The size and the obscurity of the "custom builds" in OpenLayers documentation could become a barrier to adoption when Drupal site builders are choosing between the various map modules available.

I propose a few remedies.

  1. Document the custom builds in this module. Point to http://docs.openlayers.org/library/deploying.html and http://openlayerer.appspot.com/.
  2. Associate preset options and use cases with the pieces of OpenLayers JS library and label these things consistently using the terminology OpenLayers uses so the site builder knows which pieces are relevant for her preset options and use cases.
  3. Reflect on the presets and uses and give the user a direct link to a custom build using the Openlayerer application.

I don't know if the last option is possible at all, but that's the kind of effortlessness this module needs. It's a dazzling array of options for a very powerful and mature JS application library, but this library could be just as useful for people who want to plot some points on a map. Let's give the user some training wheels for the littlest use cases.

I can help out with #2 in October after I read up on it. :-)

Comments

zzolo’s picture

@bangpound

Thanks for the insight. You make very valid points. Here's what I think:

1) We can definitely add documentation to the existing version with links and maybe some helpful procedures in the settings form.
2) We can add another advanced help page to go into details about what parts do what.
3) This is more for tmcw as he has been the main developer of the openlayerer. It would be really cool to have some way of the user to do this from the Drupal interface.

We are still growing up as a module for everyone. :)

tmcw’s picture

Hey, there are a few things floating around in this space which I'd like to work on.

OpenLayerer is hopefully a driver for a better build stack for OpenLayers. I have a couple of issues open on the openlayers trac about merging changes back in which will make the build tools less scary for people who are developers to the degree that they'll want trunk openlayers and can run python, etc. This opens the possibility of, say, openlayers builds from trunk being automated with drush make, etc.

I think that openlayerer could take some query params which autofill the form, and the openlayers module can possibly keep track of javascript dependencies on a very simple level, since the core module should only require the required parts of openlayers, and then all other requirements will be aggregated from the set of behaviors enabled. However, having one site be the one-stop shop for openlayers builds, and one on google app engine, is probably not idea. When openlayerer is stable, I'm hoping that it or a completely different app built on the build tools will be the standard, as in on openlayers.org.

Also, we need to figure out a solution for the rest of the parts of openlayers, and I probably need to roll a patch regarding some silly theme switching. Basically, you can't just have an OpenLayers.js file and be done with it, you'll need images and a css theme.

zzolo’s picture

Status: Active » Fixed

Documentation added: http://drupal.org/node/587392

For 2.x, we should be looking at some sort of "automatic way" to do this.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.