Re: R: JBoss Portal and encodeNamespace

[Scott O'Bryan]

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 <[EMAIL PROTECTED] 
> 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 <[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, 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
>>>>
>>>>
>>>>
>>>
>
>