I, on the other hand support the idea of a flag day.
And a deep apology from the community that such a crucial mistake has
been made.
This I support for the future well-being of Laszlo platform.
Certainly we can't start fucking around with the consistency of the
attribute naming system?!?.
Just do what you have to (Tucker) and be done with it :-)
name is a name, not an "on".
Yours truly,
Rami Ojares
fwiw in my personal implementation of laszlo in python, the handler
looks like:
<handler on="init">
...
</handler>
and there could be used a constraint in the "on" attribute, at
constraint-time (pre-init) only, which is something that'd be cool to
update to be fully run-time enabled. hmm. Might be too radical a
change for OL but it does clean up the attribute collision. I support
the extra handler functionality, in general.
just 2 cents
On Fri, 19 Feb 2010 13:11:07 -0700, 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).
