Ok, I got it. I'm mainly telling you this so that you can defend your opinion to the JBoss guys. Many Portal developers, I have found, like to use the excuse that the spec "DOESN'T" say I can't do something. Fortunately there is a lot of "implied" behavior. So this should help you file a bug with JBOSS to get this fixed. :)
Javadoc for JSR168 getNamespace method:
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@example.com> 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
> (but not a Keyword or BooleanLiteral or NullLiteral)
> *IdentifierChars* *JavaLetterOrDigit*
> any Unicode character that is a Java letter
> any Unicode character that is a Java letter-or-digit
> 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
> On the contrary, as you can read here:
> 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
> convinced I'll give up on it.
>> -----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.
>> 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 ;)
>>> On 1/30/08, Luca Castelluzzo wrote:
>>>> I've had a problem with the automatically generated id attributes
>>>> using JSF in a JBoss Portal portlet.
>>>> This JSF tag:
>>>> id="jbpns_2fores_2fUtilità_2f...[too long]"
>>>> name="jbpns_2fores_2fUtilità_2f...[too long]"
>>>> Unfortunately, my portlet's namespace contains an accented
>>>> which is perfectly legal for the JSR 168, but is illegal for an id
>>>> in html. Actually, this character is converted to à into the
>>>> page, but this is illegal too.
>>>> I've done a search in MyFaces code and found the reason: these id
>>>> are built by calling the encodeNamespace of
>>>> method relies upon the JBoss Portal namespace:
>>>> return name + ((RenderResponse) _portletResponse).getNamespace();
>>>> I think I'll solve the problem by manipulating the portlet's
>>>> the encodeNamespace method.
>>>> I just want to make you aware of this issue.
>>>> Thank you for your great job with MyFaces.