[Laszlo-dev] API enhancement proposal for <handler>

[P T Withington]

One of the goals is to have <handler> be the declarative way to create a delegate.  But, I'm not proposing that you will be able to constrain any of the attributes of a handler other than its `enabled` attribute.  The other attributes would be "final", i.e., you can initialize them once at construction time.  I believe this handles the most common cases.

For the situations you describe, I would expose (actually, just document) the 'register', 'unregister' and 'unregisterAll' methods, which you could call in script to handle cases where a single handler needs to be registered on multiple events, or registered/unregistered dynamically.

As Norm has pointed out though, the current proposal is too complex, because the meaning of `name` is context-sensitive.  I need to come up with a better proposal.  I regret having used `name` as the attribute that names the event to be handled.

On 2010-02-17, at 16:59, Rami Ojares wrote:

> Would it also be possible to change dynamically the value of the reference attribute.
> (Causing deregistering/registering the delegate).
> And would it be also possible to register the handler to many event souces (= having multiple values for reference attribute).
> Just asking this because without these features handler tag can not replace Delegate class.
> 
> - rami
> 
>> Recent discussions motivate being able to dynamically specify the event that a handler is attached to and being able to dynamically enable/disable handlers[1].  Currently, handlers can only be declaratively attached to events by:
>> 
>>   <handler name="eventname" ...
>> 
>> We propose to add two new attributes to the<handler>  tag:
>> 
>> 1.<attribute name="event" type="expression" />
>> 
>> If supplied, the handler will be registered to handle the event that is the value of `event`, or if `event` is null, the handler will not be registered to handle any events (it will have to be registered in script).  When `event` is supplied, `name` is optional, but if supplied, will be the name by which the handler can be referenced in script.  E.g.:
>> 
>>   <handler name="startCheck" event="null">
>>     ... startCheck body ...
>>   </handler>
>>   <handler name="hideTip" event="null">
>>     ... hideTip body ...
>>   </handler>
>>   <handler name="oninit">
>>     startCheck.register(parent, 'onmouseover');
>>     hideTip.register(parent, 'onmouseout');
>>     hideTip.register(parent, 'onclick');
>>   </handler>
>> 
>> 2.<attribute name="enabled" type="boolean" />
>> 
>> If supplied, this attribute controls whether or not the handler is enabled (will react to the events it is registered on).  This can be more efficient than unregistering/reregistering events.  E.g.:
>> 
>>  <window>
>>    <handler reference="lz.keys" name="onkeydown" enabled="classroot.haswindowfocus">[*]
>>      ... will only execute on key down when this window has focus ...
>>    </handler>
>>    ...
>> 
>> Your comments are solicited.
>> 
>> ---
>> 
>> [1] See http://jira.openlaszlo.org/jira/browse/LPP-7816
>>   
>