Adding event handling infrastructure in geo.object about geojs HOT 5 CLOSED

I am liking it, but it seems somewhat complex that you need to check that arg.layer !== this, though I don't claim to understand the nuance required here. Also, could you just pass the string "pan" as the first argument to on()? Seems that would be more jQuery-like.

from geojs.

On Fri, Mar 14, 2014 at 8:36 AM, Jonathan Beezley
[email protected]:

In this commit 73257427325742,
I have add a jQuery like interface for binding and triggering events. The
idea is that classes will interact with each other like this (for example
panning in the layer class)

this.map().on(geo.event.pan, function (arg) {
if (arg.layer !== this) {
this.trigger(geo.event.pan, arg);
}});this.on(geo.event.pan, function (arg) {

// layer specific implementation here

this.map().trigger(geo.event.pan, arg);});

The only problem is that this kind of propagation through the tree will
have to be coded for every event type. I'm wondering if it might be useful
to add standard parent/children attributes to the object, then the mapwould copy its
layers into children and layer would put the map in parent and the
renderer in children, etc. This way we could implement this generically
in geo.object. Also, we would want to bind the triggerer to this in the
handler to prevent circular propagation. What does everyone think?

I don't have a problem with adding this if . Maybe it should be a subclass
of object though, so only those classes that need this parent/child get it?

from geojs.

The difference between this and jQuery is that we need to propagate events both up and down the tree, so we need a mechanism for preventing circular propagation. I'm up to suggestions on how to do this. Also, geo.event.pan is defined here. It is just a string, but I think the idea is to support something like namespacing in the events.

from geojs.

Okay, here is the latest interface 03e03a2.

I changed the routing as follows:

• An event is triggered on an object.
• If the object has a parent and the parent did not trigger the event, it propagates the event up the tree and returns (not calling its handlers).
• It calls all of its own handlers.
• It triggers the event on all of its children.

It seems we also need a mechanism for preventing propagation. Maybe a stopPropagation callback as an extra argument to the handler?

@cjh1 The object defaults to no parents or children, so everything will work without a tree structure; however, I'm not opposed to moving this to a subclass.

from geojs.

@jbeezley I like the idea of making it generic. So I guess this could be applied to features as well? Any thought on that? Also, I think moving the parent / child to to something like sceneObject (or something similar) would be appropriate in that case; map, layer and renderer could use that as the base class.

from geojs.