[Laszlo-dev] LzEvent.sendEvent -> sendEvent
jgrandy at openlaszlo.org
Wed Nov 1 07:13:58 PST 2006
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...
> On 2006-10-25, at 11:57 EDT, Jim Grandy wrote:
>> Just noting we have bugs in JIRA on this theme:
>> 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
>>> 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
>>> back with/can pass more than one argument.
>>> On Oct 23, P T Withington wrote:
>>>> What do people think about changing the idiom:
>>>> 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).
More information about the Laszlo-dev