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
