I'm going to go ahead and finnish up the extended versions o f these components, as there really isn't any harm in supporting the escape attribute for people who are stuck for whatever reason using .jsp format.
I'll slap together some new examples showing off the escape attribute, as well as the alternative of using unicode in .jspx.
Thanks for spelling all this out for me :)
On 11/9/05, Adam Winer <[EMAIL PROTECTED]> wrote:
Well, it all depends on where the text is coming from; but, say it's
coming from a Java ListResourceBundle; instead of containing:
"ꯍ"
it should contain:
"\uabcd"
If it was hardcoded in a .jspx documents, or in any XML file, then an NCR
is great, since that'll get decoded by the XML processor, be seen
as a Java Unicode character, not an NCR string, and again be
handled fine.
The only significant issue I really see is when you're dealing with
ordinary .jsp files, where you don't have Unicode escaping, NCRs
don't get decoded before being passed to Java, etc., and you're
forced to either resort to NCRs + escape="false" or to entering
characters directly in the target character set.
And, my harsh answer to that problem is that developers should stop
using old-style .jsp file format, which is hideous, and use .jspx documents
instead.
-- Adam
On 11/8/05, Grant Smith <[EMAIL PROTECTED]> wrote:
> Adam, I'm not quite sure I understand what you're saying here. Can you give
> an example in the context of the original user's problem ?
>
> On 11/8/05, Adam Winer <[EMAIL PROTECTED]> wrote:
> > On 11/8/05, Grant Smith <[EMAIL PROTECTED] > wrote:
> > > In general this is true. However, there are legitimate reasons for using
> NCR
> > > over Unicode. See
> > >
> > >
> http://www.w3.org/International/questions/qa-escapes.html
> > >
> > > for some of them. I'd like to see both options available.
> >
> > As I see it, this refers to using NCRs over UTF-8/UTF-16, etc. encoded
> > text. Not what I'm talking about.
> >
> > I'm talking about Java-unicode-escaped text. E.g. "\u82eb", such that
> > the Java strings you pass to JSF are Unicode, This is, IMO, always
> > preferable - when you're holding onto a Java java.lang.String object,
> > it should be Unicode escaped.
> >
> > The issue of how you store those strings and escape them when they're
> > stored externally to your Java code (resource bundle, database, etc.)
> > is a separate question, and should be whatever is natural to that
> > datastore. All I'm saying is that when you get it actually into
> > Java,. NCRs are bogus, pure Unicode is the right way to go, and then
> > you let JSF handle the escaping for you.
> >
> > At any rate, escape="false" assumes that you're writing the text out
> > as a text node, which will never work for <h:inputText>, for example,
> > since it's written as a "value" attribute. So, right there you've got
> > a case where NCRs are dead in the water. And it's a bad move to
> > encourage people to set escape="false" all over the place, 'cause then
> > they're opening themselves up to cross-site scripting attacks.
> >
> > -- Adam Winer
> >
>
>
>
> --
> Grant Smith
>
--
Grant Smith
