I must say I don't understand the desire to have a it all literal or
all ognl between specs and templates. I have thought ognl in specs
and literal in templates made absolutely perfect sense in 3.
Jamie
On Jul 26, 2005, at 5:59 PM, Paul Ferraro wrote:
Howard Lewis Ship 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>
The fact that the chosen binding prefix and the component's
parameter name happen to be the same in this example does not
bother me. To call them redundant seems superficial.
vs.
<a onclick="listener:doClick"> ... </a>
Makes no difference to me ... except that "onclick" is a common
HTML attribute often used as an informal parameter for javascript
actions (e.g. confirmation windows). You'll have to pick a
different name.
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?
I prefer to have "literal:" be the universal default.
If the default binding prefix is "ognl:" then I think users will be
more inclined to use ognl to define literal expressions (as in 3.0)
rather than use the more efficient literal binding.
e.g.
<property name="message" value="'This is my message'"/>
... may be more attractive (since it requires less typing), but is
less efficient than ...
<property name="message" value="literal:This is my message"/>
I think the best strategy is to choose the most consistent approach
as the default (i.e. literal everywhere) and allow users to
override it to their hearts' content.
Paul
---------------------------------------------------------------------
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]
