He asked for suggestions. I supplied a suggestion. Its necessary to first weigh all possible options, before making a decision. I don't have a vested interest in which possible option is implemented.
On Fri, Feb 19, 2010 at 3:34 PM, jamesr <[email protected]> wrote: > You can do anything you want - so long as you can support compile flags to > have legacy and non-legacy modes. I can do what i like -- because i wrote my > own. > > And i could write my own javascript implementation of the same too. But i > stand by laszlo and use it daily, especially being a former employee. > > What I was able to do - write a lzx clone from the ground up so that i could > make a design that took into account all of the research that brought laszlo > to the point it is, minus many circuitous routes, was one of the most > educational experiences i've had. > > Code compatibility is something you can a) (microsoft) cling to for dear > life or b) (apple) provide environments that allow for successive porting. > > Or you can ignore it. I'm not on any side of that debate, but like to toss > in perspectives from time to time. > > - jamesr > > > > On Fri, 19 Feb 2010 16:24:53 -0700, Rami Ojares <[email protected]> > wrote: > >> 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). >>> >>> >> > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >
