[Laszlo-dev] OpenLaszlo Event Model

[André Bargull]

I've just implemented this "new event-system" locally, and amazon-demo 
start-time was before my change by about 1350-1450ms [1], with my 
changes it was dropped to 980-1050ms. And I didn't even updated anything 
of the LFC to use the new, more effective methods...

[1] FF3 + FP10 (debug-player), demo compiled for swf9 non-debug, time 
measured with <inittimer>

On 10/29/2008 1:14 AM, André Bargull wrote:
> I've started to reconcile with that idea and made up a some code 
> snippets. IMO, there is at least one thing we definitely need to 
> change: the current for API for LzDelegate#unregisterFrom(..). At the 
> moment, the method signature is "function unregisterFrom 
> (event:LzEvent)", this needs to be parallel to 
> LzDelegate#register(..), so "function unregisterFrom 
> (target:LzEventTarget, type:String)".
> (The attached code is neither complete nor fast, I just wanted to be 
> minimalistic, but also not too abstract.)
>
>> 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.