This isn't very pretty, but .. <handler name="eventname" ...
We propose to add two new attributes to the <handler> tag: 1. <attribute name="delegate" type="expression" /> I changed this to "delegate" as that is what it is and the term "event" already has existing connotations in the user's mind. Then internally set the "name" attribute to the "delegate" attribute if it was specified. Basically, the calling convention is just a fiction. But internally the correct attribute names are set to their correct values. Not very pretty, but I think that people would quickly grow accustomed to it. On Fri, Feb 19, 2010 at 12:11 PM, P T Withington <[email protected]> wrote: > On 2010-02-18, at 23:11, Norman Klein wrote: > >> I'm not sure what all of your goals are concerning an API for the >> declarative specification of a delegate. > > The goal is to make it so a user never has to write `new LzDelegate` in > script, which the currently do have to do if they want to be able to get a > handle on the delegate object to either dynamically attach/detach it to one > or more events, or dynamically enable/disable the delegate. So really, just > to give a way to: > > a) address the handler (currently the handler is anonymous) > b) indicate that the handler is not to be attached to any event (initially) > c) indicate the handler is to be attached to an event that may be dynamically > computed (i.e., may not be accessible as a named property of a node). > > All of these goals require being able to name the handler in script. The > easiest way to do that would be to assign the handler to a property of the > parent node, and the syntax for that for any other property (attribute or > method) is to say `name="propertyname"`. > > Which is why I regret having used `name` in <handler> to mean the name of the > event property it is to be attached to. I should probably have used either > `event` or `eventname`. But now, I am looking for some way to achieve the > above without having to have a "flag day". > >> But this is a suggestion that >> you might find interesting. >> >> I don't think its important to be able to "name" handlers as a handler >> only provides a binary operation: it either handles an event or it >> doesn't. How it handles an event is an implementation detail that >> should be private to an object. Currently, OL only supports a direct >> handler implementation: >> >> <handler name="oninit"> >> .... >> </handler> >> >> My suggestion would be to also support an indirect implementation, >> that follows the procedural paradigm, allowing methods to be specified >> within a handler. A "method" attribute could be used to select from >> amongst several available implementations. >> >> <handler name="oninit" method="meth1"> >> <method name="meth1"> >> .... >> </method> >> <method name="meth2"> >> .... >> </method> >> </handler> >> >> This is only one possible choice. You might find it better to use an >> indexed array to support the current handler. In which case, it would >> default to a zero offset and possibly also support "first", "last", >> "next" and "previous" operations. >> >> A handler could then be referenced and set as >> obj.oninit.setAttribute("method", "meth1"); >> or >> obj.oninit.setAttribute("method", 1); > > As things stand today `oninit` is the name of the <event> the handler is > registered on, not the handler itself. I.e., `oninit` will be an <event> > >> I like the idea of having the methods enclosed within a parent handler >> tag as it provides locality and complements the appearance of the >> direct implementation handler. But this comes with the cost of >> reusability. It might be better to represent the handler as an end >> node that references any method defined within the object. >> >> <handler name="oninit" method="meth1"/> >> >> <method name="meth1"> >> ... >> </method> >> </class> >> >> As methods are inherited by an extending subclass -- also allowing >> them to be overridden, while the methods contained within a handler >> would need to be restated. > > The above is what is presently implemented. Although you hint at another > pattern that would be enabled by being able to name a handler -- to change > the method that the handler invokes dynamically. But this is not part of the > current LzDelegate protocol, and I don't think we want to go that way > (because it is possible in some runtimes to implement a handler directly as a > closure, eliminating the intermediate object).
