I'm currently traveling right now and don't have access to the spec.
The guideline below in ONE of the guidelines but not the only
guideline. I know I've seen further guidelines in the spec on this and
even posted a message about it here about a year ago concerning
another portal. The issue here is that unicode namespaces may be ok
for certain markup. Since the portal is responsible for that markup,
what they return MUST comply with the policies of that markup.
The 168 spec guarentees that the namespace is unique. It does not
guarantee that a modified namespace is unique. Anyway, I'll find the
relivant portions in the spec for you. I think it might be in the
javadoc but I can't remember offhand.
On Jan 31, 2008, at 2:41 AM, "Luca Castelluzzo" <[EMAIL PROTECTED]
> wrote:
Hi Scott,
I'm afraid JBoss Portal complies with the JSR 168.
This is an excerpt from page 53 of JSR168-spec:
The getNamespace method must return a valid identifier
as defined in the 3.8 Identifier Section of the Java
Language Specification Second Edition.
This leads to page 20 of the Java Lang Spec 3.0 which defines
identifiers
as:
*Identifier*:
*IdentifierChars*
(but not a Keyword or BooleanLiteral or NullLiteral)
*IdentifierChars*:
*JavaLetter*
*IdentifierChars* *JavaLetterOrDigit*
*JavaLetter*:
any Unicode character that is a Java letter
*JavaLetterOrDigit*:
any Unicode character that is a Java letter-or-digit
[omissis]
A “Java letter” is a character for which the method
Character.isJavaIdentifierStart(int) returns true.
A “Java letter-or-digit” is a character for which
the method Character.isJavaIdentifierPart(int) returns true.
The method Character.isJavaIdentifierPart('à') returns true, so 'à'
can be
part of the Java identifiers and then part of the JBoss Portal
namespaces.
On the contrary, as you can read here:
http://www.w3.org/TR/html4/types.html#type-id
only common letters (without accents) may be part of the content of
an "id"
attribute in HTML. Actually, what my rendered page ids contain is an
ampersand which is forbidden as well. There must be a conversion
from 'à' to
à somewhere in MyFaces code.
I'm not going to spend more time to defend my opinion, so if you are
not
convinced I'll give up on it.
Regards,
Luca
-----Messaggio originale-----
Da: Scott O'Bryan
Inviato: giovedì 31 gennaio 2008 7.54
A: MyFaces Discussion
Oggetto: Re: JBoss Portal and encodeNamespace
Martin, this is the correct implementation in both the MyFaces Bridge
and the 301 bridge. JBoss's encodeNamespace method needs to return a
valid namespaced id.
Scott
Martin Marinschek wrote:
Hi Luca,
it would be great if you could open an issue - and maybe you could
solve this generally by doing some encoding of the problematic
characters - whatever this encoding might be. If you attach a
patch to
the issue, it might as well be committed ;)
regards,
Martin
On 1/30/08, Luca Castelluzzo wrote:
Hi,
I've had a problem with the automatically generated id attributes
while
using JSF in a JBoss Portal portlet.
This JSF tag:
<h:form>
Becomes:
<form
id="jbpns_2fores_2fUtilità_2f...[too long]"
name="jbpns_2fores_2fUtilità_2f...[too long]"
method="post"
action="[omitted]"
enctype="application/x-www-form-urlencoded">
Unfortunately, my portlet's namespace contains an accented
character
"à"
which is perfectly legal for the JSR 168, but is illegal for an id
attribute
in html. Actually, this character is converted to à into the
rendered
page, but this is illegal too.
I've done a search in MyFaces code and found the reason: these id
attributes
are built by calling the encodeNamespace of
PortletExternalContextImpl.
This
method relies upon the JBoss Portal namespace:
return name + ((RenderResponse) _portletResponse).getNamespace();
I think I'll solve the problem by manipulating the portlet's
namespace
in
the encodeNamespace method.
I just want to make you aware of this issue.
Thank you for your great job with MyFaces.
Luca
