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