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