I prefer option #2 where the absence of a binding prefix indicates a
literal, _both_ in templates and specifications.
Informal parameters are always treated as literals, unless otherwise
indicated. Formal parameters should be no different.
As I indicated earlier, I am all in favor of this. I'm not sure that
"literal" is the best default, but I think the default should be
consistent
in both contexts.
If implicit components are not used then in the template only literal: is
used.
In most cases I use ognl: binding in the specs (even now when the new
bindings are available).
That's why I think that in the spec. the default should be ognl:.
#2 is definitely an improvement over #3.
The only purpose for #1 is to save typing time. Unfortunately, I find
that the time saved on typing is eclipsed by the time spent looking up
the default binding prefix values in the component reference (it isn't
always as obvious as the example below).
To avoid this nuisance, I find myself /always/ using a prefix - but is
this not the opposite of this enhancement's intent?
Rather than throw the whole thing out, would it be better to try and
address
these ambiguous circumstances? It seems the one that keeps being
mentioned
is literal VS message. Maybe there could just be a Tapestry property that
switches between the two. I don't know that yet another configuration
value
is the right solution, I'm just throwing that out there.
I think that consistency is the key: I would prefer the default-binding to
be removed.
Another configuration option or other solution would make bindings only more
complicated which would confuse users.
Br,
Norbi
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
