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:


java.lang.String getNamespace()
The value returned by this method should be prefixed or appended to elements, such as JavaScript variables or function names, to ensure they are unique in the context of the portal page.

the namespace
Variable and function names are called identifiers and are identified in the Javascript 1.2 specifications as:

...an unlimited length sequence of ascii letters and digits, the first of which must be a letter.  Letters include both upper and lower case ASCII characters (A -Z and a-z), the ASCII Underscore Character (_), and the ASCII Dollar Sign ($).

Javascript 1.1 was the only available javascript out at the time of the spec release and internationalization of Javascript identifiers was not added until 1.3 and even then only under certain circumstances.  I *BELIEVE* JSR 286 further identifies the namespace and being something that may be appended to element names because AJAX was not around when the Portlet Spec came out and the need to namespace these elements was not foreseen.

In either case, the JSR-301 spec for JSR-168 and JSF 1.2 adds a naming container for the purposes of namespacing id's of elements in a portal environment.  This naming container uses the namespace as its key.  There is a JBoss person on this EG so presumably they are aware of the issue in their portal anyway.  :)  If they don't agree, do me a favor and let me know so that I can bring this up in the JSR-301 Expert Group and see if there is a way to solve this.  I think, though, that manipulating the namespace is very dangerous and may make it impossible to properly find elements in most cases...

Good Luck.


On Jan 31, 2008 8:22 AM, Scott O'Bryan <darkarena@gmail.com> wrote:
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" <luca.castelluzzo@linksmt.it
 > 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
> &#224; 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&#224;_2f...[too long]"
>>>>     name="jbpns_2fores_2fUtilit&#224;_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 &#224; 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