[Laszlo-dev] LzEvent.sendEvent -> sendEvent

[Jim Grandy]

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?
>>
>