Re: R: JBoss Portal and encodeNamespace

[Michael Freedman]

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 <[EMAIL PROTECTED]> 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" <[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 > &#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="" >>>>     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 >>>> >>>> >>>> >>> > >