If in doubt, go with a stricter and more consistent approach.. The migration path from that to something with more "magic" is feasible, but not the other way around. Making the "magic" go away will be more painful on users.
Is this namespace-like idea pluggable? Who can decide where/what is an appropriate default for a certain case? How is that choice made obvious to users? I personally had no issues with the whole notion of 3.0 calling inherited methods, like "listeners.foo".. I thought that was nice and consitent.. Now there are these special namespaces, and I'm not even sure of the real value... :) viktor On 7/26/05, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > Now, we don't want to make the same mistake as Sun did with Generics; > how do we reach concensus on wether to include or strip out > default-binding? Another vote? > > I tending towards leaving it as is, but there are some good ideas on > how to processed if we strip default-binding out. > > For example, changing the various link components to take a "onclick" > parameter (as a rename of "listener"), i.e. > > <a listener="listener:doClick">...</a> > > vs. > > <a onclick="listener:doClick"> ... </a> > > The lack of repetition in the second example is desirable. > > I'm also tending towards default of literal: in a template, default of > ognl: in XML. But there's that consistency issue again; perhaps is > should be literal: everywhere for best efficiency? > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
