If we carry this to its conclusion, I would see us making an
LzEventTarget mixin that would implement addHandler, removeHandler,
and sendEvent. This would be mixed in to LzNode and any other class
that expects to dispatch events. This would make LzEvent and
LzDelegate internal interfaces. This would be a pretty major change
to the Event/Delegate API, but I think it would bring the API much
more in line with what DOM2 does, possibly making it more
understandable.
The side-benefit would be that LzEventTarget could handle the leak
management that is now distributed between LzEvent, LzDelegate, and
LzNode; and the manual leak management that must be handled by anyone
making their own delegates.
Do we want to go this way at this point?
On 2006-11-01, at 12:37 EST, Jim Grandy wrote:
On Nov 1, 2006, at 8:22 AM, P T Withington wrote:
On 2006-11-01, at 10:13 EST, Jim Grandy wrote:
On Oct 31, 2006, at 3:07 PM, P T Withington wrote:
It's just a really clean mechanism that works well.
Ok. Hm. Initially, I think I will just pass the event sender as
a second argument. I'm just trying to limit the size of this
change. This can easily evolve to an event descriptor in the future.
How would it evolve cleanly? I'd encourage just adding the event
descriptor, even if it has just the event sender in it. This way
app developers can benefit immediately by creating their own event
parameters. Another benefit: classes of events can use the same
parameter names, and so you can write code that processes multiple
types of events generically.
It seems a shame to have to cons up an event descriptor if most
handlers don't need it.
I think it's worth it. Plus, in DHTML we could potentially just
pass through the HTML event descriptor to save a cons.
Probably so. But I'm not sure we want to guarantee all the
information that is in an HTML event descriptor for all platforms.
Well no, we wouldn't guarantee it. It would be a power-user thing,
the equivalent of dropping into ActionScript and using Flash APIs
in LZX.
It also seems a shame to have to burden all event processing
with the overhead of apply, just so one or two handlers can be
passed multiple arguments.
Should we just add the target as the second argument to handlers
for those who need it, and make handlers that need multiple
arguments use an object?
We could be _very_ clever and look at the number of arguments
the handler expects and create an DOM2-like event object only if
the handler expects a second argument.
I kind of like that, but doing that check on every handler in the
chain might be expensive...
It could be done at the time the handler is added to the event.
If any handler expects the second argument, then the send loop
will create the descriptor and pass that.
Thoughts?
