On Oct 31, 2006, at 3:07 PM, P T Withington wrote:
So, thinking about this, 1490 is basically asking for the 'target'
to be passed. In DOM1 the target is 'this' because adding a
handler adds it as a method on the event sender. That clearly
can't work for us, because 99% of our handlers are methods on
another object. In DOM2, what a handler gets is an event
descriptor object, with lots of properties. Always at least the
target and some other stuff depending on the type of the event. I
am wrestling with whether it is more important to pass multiple-
values to a handler or to pass more information about the event.
I had to make this choice in a couple of projects in the past, and
was always glad in the end to have chosen an event descriptor. There
are a number of ways this can be useful:
- as you mention, it is a clean way of passing complex information
around as part of custom events
- event handlers can piggyback information on the event for use by
handlers further up the event chain
- the kernel/LFC can add cheaply-computed secondary information (such
as whether a click is part of a multi-click) to the event.
- it makes it *possible* to pass through extra pointer info (button
number, pressure/angle for tablets) when available without going
through painful acrobatics
It's just a really clean mechanism that works well.
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.
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...
Thoughts?
On 2006-10-25, at 11:57 EDT, Jim Grandy wrote:
Just noting we have bugs in JIRA on this theme:
http://www.openlaszlo.org/jira/browse/LPP-1490
http://www.openlaszlo.org/jira/browse/LPP-383
Elliot says:
LPP-1490 is much more useful and the last work-around that I did
for mouse
track events was really hacky and didn't work 100% of the time. I
created an
invisible view that listened for all mouse events, set a globally
accessible
var with the currently moused-over view, and then dispatched the
event to the
correct view underneath.
On Oct 23, 2006, at 2:30 PM, Adam Wolff wrote:
If we do this, can we also make it variadic so that delegates get
called
back with/can pass more than one argument.
A
On Oct 23, P T Withington wrote:
What do people think about changing the idiom:
<event>.sendEvent(<value>);
to:
sendEvent(<event>, <value>);
?
This would make it easier to detect errors (trying to send an
event to a
non-existent event) and to optimize (to not bother if there are
no listenters
for the event).
Comments?
