[Laszlo-dev] OpenLaszlo Event Model

[P T Withington]

That's implicit in the 'long form' version of events.  If you use the  
'long form' API, you will get an event object (which will have a  
structure based on the type of event) rather than just a single  
value.  At least, this is what I was trying to get at when talking  
about dispatchEvent vs. dispatchSimpleEvent.  We want to keep a simple  
path that can be used by constraints and be very efficient.  Maybe we  
don't expose that path at all at the LZX level.  And then we want a  
DOM2-style path that passes around full event objects with all the  
DOM2 information (e.g., the event target, the node currently handling,  
event-specific attributes such as mouse x/y or keyboard key/modifiers,  
etc.)

On 2008-11-03, at 16:01EST, Max Carlson wrote:

> While we're on the subject, it would be nice if there was a way to  
> store  data when registering the event that's returned when the  
> event fires.  This is a common pattern for DHTML developers -  
> methods registered for events often closes over instance-specific  
> values that are then available to the callback...
>
> Lorien (cc'd) made a proposal a while back along these lines...
>
> P T Withington wrote:
>> We have an (improvement suggestion)[http://jira.openlaszlo.org/jira/browse/LPP-6034 
>> ] to change the structure of the event system to be more efficient  
>> and more DOM-like.  I recently added a comment:
>>> What we really want to do is get more in line with http://www.w3.org/TR/DOM-Level-2-Events/
>>>
>>> This would mean that LzEventable would become EventTarget, and  
>>> LzDelegatable [LPP-7037] would become EventListener.
>>>
>>> The major impact on our system is that LzEvents would no longer be  
>>> objects in themselves, but simply names (event types). This could  
>>> reduce the overhead of events, but would mean a big  
>>> incompatibility. Instead of:
>>>
>>>  <target>.<event>.sendEvent(<value>);
>>>
>>> you would have to say:
>>>
>>>  <target>.dispatchEvent(<event>, <value>);
>>>
>>> [In DOM2, dispatchEvent takes only an Event as its argument, the  
>>> event is an object that has attributes such as the event name  
>>> (type), state, and depending on the type of the event, additional  
>>> information -- what we usually pass as the single <value>. If we  
>>> want to be more compatible, perhaps we should implement the  
>>> `dispatchEvent` interface and another `dispatchSimpleEvent`  
>>> interface that handles most of our events. Otherwise the overhead  
>>> we save by not having LzEvent objects to attach listeners to will  
>>> be replaced by allocating an Event object every time you want to  
>>> send an event.]
>> I'd be interested in other ideas and opinions.
>
> -- 
> Regards,
> Max Carlson
> OpenLaszlo.org