Re: R: JBoss Portal and encodeNamespace

[Scott O'Bryan <da...@gmail.com>]

Hey Mike,  thanks for following up on this.  I was beginning to think  
301 missed somthing even though I was sure on the intent of the API.

Nice to get some official clairification.

On Jan 31, 2008, at 1:36 PM, Michael Freedman <michael.freedman@oracle.com 
 > wrote:

> FYI ... I contacted the JBoss rep in JSR 301 and he indicates this  
> is a known problem which will be fixed soon:
> You are correct: http://jira.jboss.com/jira/browse/JBPORTAL-1875. ....
> And this should be fixed in the upcoming 2.6.4 release (Feb 11)
>    -Mike-
>
> Michael Freedman wrote:
>> Yes, JBoss likely complies with the spec in that the TCK tests are  
>> too loose.  I will forward this to the JSR 286 spec lead for  
>> comment/potential improvement in the 286 spec -- but as Scott  
>> points out the use of getNameSpace is clear -- it is to be used for  
>> prefixing ids/names in markup responses to guarantee page  
>> uniqueness.  As the id being returned doesn't satisfy this I would  
>> agree that it is a bug.
>>      -Mike-
>>
>> Scott O'Bryan wrote:
>>> 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:
>>>
>>> getNamespace
>>>
>>> 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.
>>>
>>> Returns:
>>> 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.
>>>   Scott
>>>
>>> Scott
>>>
>>>
>>> On Jan 31, 2008 8:22 AM, Scott O'Bryan <da...@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, s 
>>> o 'à'
>>> > 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
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >
>>> >
>>>
>>
>