[xinf] Events counter-proposal

[daniel fischer]

"Mark Winterhalder" <mark13 at gmail.com> (on Sun, 9 Jul 2006 17:03:21 +0200):


  > First of all, has for..in a fixed order in haXe? I always assumed the
  > order to be random.

i guess the order is undefined-- in the Test.hx i posted, it's actually FILO- so handlers attached later get the event first, which might be fine, or not. I've asked about wether enforcing a specific order (or priority) would make sense...

and indeed, if we do the stopPropagation() thing, some order would be neccessary, or it doesnt make sense at all.


  > Then, why should one event be allowed to stop the event from being
  > delivered to other subscribers? I know this is because of the
  > bubbling, but I'd solve the bubbling by calling something like
  > parent.onEvent( event ) inside a handler.

well- first, it's not about the bubbling only. the event model described doesnt inherently support bubbling (as EventDispatcher has no concept of a parent). It could do so- but somehow i wouldn't like it :)

i'm unsure, but why do mostly all event implementations provide something like stopPropagation()? maybe you want to stop the event from being propagated to the "default" handler (whatever the definition of that is)...?

as for parent.onEvent() (or rather parent.dispatchEvent()?), i don't think that makes sense- the point of bubbling is that a parent can catch children events without those having handlers at all.

Imagine some parent that does the interaction logic (handle onClick), and has children that are "mere" display things- you'd want to catch the onClick if it's on a child, too. Do you really want to register a handler for every child, then bubble "manually"? Or register the same event handler on the parent and all children? I think not- and this is what bubbling is for.

the whole bubbling and stopping thing is definitely open for debate- i've just added it intuitively. for example, is making "bubbles" (or, canBubble) a property of the EventType good? would it better be a property of Event, so bubbling can be stopped at any stage of event handling, or set per-event? I'm unsure as yet. Also, the current implementation of EventDispatcher might provide a good starting point (and proof that this model works), but is surely not set in stone.

But anyhow, these are implementation details and/or "higher-level" things, they don't dispute the basics here (which i regard as a good thing :) If we want, we can blow this up to be even more like DOM Events except that our EventType is a proper class (and associated string, and Event subclass) instead of simple strings, and thus we dont have to cast() or do any other dynamic untyped stuff -- with all the CAPTURE/AT_TARGET/BUBBLING stuff and so on.

-dan

-- 
http://0xDF.com/
http://iterative.org/