Custom Event System?

All of the 0.1 and 1.x custom events are eliminated in 2.x, and we're only using the Drupal behaviors stack and the OpenLayers events stack, since there's no reason to use anything else. We should, eventually, switch from Drupal's javascript events system to basically jQuery's binding system, since it'll allow us to switch everything to window.load instead of window.ready, but that's for another ticket.

I really really disagree with this. We use a custom event system for the following reason:

One of the original design goals for openlayers was to make maps, as much as possible, alterable by other modules. This is sticking to the 'drupal way'. This means making other modules able to alter maps and change layers, styles, controls, behaviors, and events. In order to accomplish this goal, we made all events be declared on the PHP side so that they have the possibility of being altered (added or removed to by other code). Without pushing the events through the php side, events can only be added, not removed.

Removing the event system is a big enough change that should have been discussed first, and it's removal should be reverted.

Of course we're working to make this module extensible by others, and the pluggable behavior system has been incredibly effective for that purpose. Defining events on the Drupal-side, though, is just not a very good idea. OpenLayers itself provides hundreds of events on every map, of which the Drupal implementation duplicated about four, and poorly. And, the idea that only via Drupal are things completely customizable is simply not the case: just like any other events in Javascript - and even better than pure events in javascript, OpenLayers events can be modified and removed by other modules [1].

On top of this reasoning, the 'OpenLayers module events system' was basically another, independent, events system grafted on top of the Drupal events system, jQuery events system, and OpenLayers events system, and there were no implementing modules which used it. Somehow, it didn't even use jQuery's syntax for binding and firing events.

So, basically, yeah - you can do everything you could do in the Drupal map-stack as you can in the OpenLayers javascript stack, and you can do it without making a new system and while maintaining some compatibility with OpenLayers-proper. If there's an exception to this, let me know, but building something like a new events system on top of something that already has a great events system is just NIH syndrome.

[1] http://dev.openlayers.org/releases/OpenLayers-2.8/doc/apidocs/files/Open...

Fundamentally what we are talking about is an application-level event 'registry' system. We are not reinventing the openlayers event system, merely organizing it in a particular manner.

A particular implementation of an Drupal openlayers map is smushing together all sorts of different behaviors and functionality from all sorts of different places and modules, built by all sorts of different people. This is pretty different from the other raw openlayers implementations i've worked on where you *know* what your putting in there. On larger raw openlayers implementations i've found a central register of events to be very useful in organizing code and knowing what's going on. On our implementation, this becomes even more useful given the number of different people, modules involved.

This kind of 'userland' event registry is *not* something that the openlayers JS project concerns itself with, nor should it be! It's the kind of consideration that is outside of it's perview of it's 'API space', and obviously belong in the 'application space', which arguably, is where our module sits.

I realize that our event system only implemented events for the map object, and layers. OpenlayersJS can handle events on pretty much every object around. However, 99% of events that you ever register when building an app is going to be on the map and on the layers. I'm happy to leave the other possible events outside our system.

What are the use cases of the old-style events system that behaviors doesn't cover? That's the real demand of this ticket, since stuff like map loading and attaching events to layers, etc., is very easily done in behaviors.

And, I'm not opposed with some sort of Drupal-centric management of events, since there is the potential for other modules wanting to automatically add them. However, I think that we can do that without much building on the javascript side, basically just tying some kind of drupal output to the native OpenLayers events system. I feel like building a new events system in Javascript, even if it is minimal and jQuery-heavy, is a bad idea. Why? Because, for instance, the old events system would have layerAdded triggered after openlayers.js adds a layer. What if you add a layer outside of the openlayers.js workflow? Using the Map object's events covers this scenario and everything else, and makes our configurations of OpenLayers less foreign to OpenLayers use as a whole.

And note that I'm simply not much of a fan of registries. Like, compare the storage of maps in 1.x to 2.x, in which we switched from a system of drupal map settings -> some kind of weird settings object -> some weird pointer to a map object, to attaching data to divs with native jQuery functions. I don't really get 'registries' on the javascript side because javascript has events and the ability to extend objects.

Anything else on this ticket?

Yeah, the thing is, if we have something like 'enter a Javascript callback *here*' in the UI, then someone will create a module that includes the necessary javascript... and they're one step away from writing a behavior, which would do the job much better. Maybe there are dirtier ways to hack this that I'm not thinking of, but it seems like having some kind of shortcut-to-javascript-attachment method just doesn't fit any conceivable use.

Anything?

Still waiting on this one. phayes, any word on use cases?

Setting as by design for now. This is two or three months stale and not actionable at all, and the issue has not come up in other tickets.