Yes - you can still use quotes around a literal, e.g.
<binding name="displayName" value="'E-mail Address'"></binding>
<binding name="displayName">'E-mail Address'</binding>

... but then the value is parsed as an ognl expression and the performance benefit of the new literal binding is lost. This was one of my arguments for making literal the default binding in specifications.

Paul

Jamie Orchard-Hays wrote:

And can't you use quotes around a literal, instead of "literal:" as a prefix? I did that a lot in 3.0 anyway.


On Aug 12, 2005, at 9:39 AM, Howard Lewis Ship wrote:

How about:

        <binding name="displayName">literal:E-mail Address</binding>
        <binding name="validators" value="validators:required,  email"/>
        <binding name="value" value="email"/>

This is legal in 4.0 as well.

On 8/12/05, Kevin Menard <[EMAIL PROTECTED]> wrote:

Howard Lewis Ship wrote:

-1

Trying to simplify, simplify, simplify the XML.  And you should be
using message: for your displayName.


I can certainly empathize with that, but it seems the cost of simplified
XML is harder to read values.  Now, I do like that I don't really  have
to think about what tag to use and that I can swap bindings out without
changing XML.  But, at least my values weren't a mess to look at.

Furthermore, being human and all, I can see myself making a typo on a
binding name here and there.  When the type of binding was an XML  tag,
validating against the DTD caught such errors quickly.  Now I need to
actually deploy, navigate to the page, see the error, go back and see
what's wrong, make the fix, redeploy, navigate to the page again, and
see that the error was fixed.

I would even be for having a type attribute in the binding tag.
Something that separates the data from its data source (limiting the
potential errors introduced when trying to modify one or the other) and could still be validated. For user created bindings, I guess you'd have
to set the type to "user" or something, and specify the actual  binding
in the value, which won't gain you a whole lot.  However, I think  this
solution will work pretty well in the general case.

As for the i18n stuff, you're probably correct, but my little sandbox
webapp really hasn't merited.  I think the spirit of my post  generally
remains unaffected by this though.

--
Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to