There's an additional point here...
in 3.x, each binding-type in the component spec had it's own xml tag...
<static-binding name="" value=""/>
vs.
<inherited-binding .../>
vs.
<binding name="xyz" expression=""/>
^^^^^^^^^^
Thus, in the 3.x world, it was explicit in the component spec
that string specified in binding was an expression... b/c it's
expression=""; So, no confusion.
in 4.0, however, there is only a /single/ binding element defined,
and the type of binding is determined by the prefix. So, my vote is
with Kevin; the default prefix between templates and component/page
specs should be the same. Whether it defaults to literal or ognl I
don't really care, although here I'm inclined to agree with whomever it
was that noted that (lazy) people (which is most of us, really. ;) would
be inclined to use ognl strings instead of the literal binding, for the
sake of brevity.
On the other hand... an ognl expression, or some other binding-type
(like listener, bean, etc.) is probably going to be used for bindings
far more often than a literal binding.
Anyway... sorry if I rambled a bit... been a long day. :)
Robert
Kevin Menard wrote:
> Jamie Orchard-Hays wrote:
>
>>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.
>
>
> Sure, once you understand it, it's easy to remember. As a newbie, I was
> burned several times by this lack of consistency. What it boils down to
> is that components defined in the HTML and in the spec are either
> equivalent or they're not. If they're equivalent, they should have the
> same semantics. I shouldn't have to worry about changing all my
> bindings when going from one to the other.
>
> It seems the two different defaults is a convenience thing more than
> anything else. On top of this, it's not even convenient for everyone,
> just those that fit this "common" usage pattern of where they choose to
> define their components. I'd rather have the consistency, which makes
> perfect sense to me.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
