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