[jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]

Thu Oct 28 11:54:24 EDT 2010

(Tweaking the subject in case folks are tuning out of our very long 
prior discussion...)

On 10/26/10 6:04 PM, Andy Schwartz wrote:
> On 10/26/10 5:10 PM, Ed Burns wrote:
>> Ok, here's what we'll do for JSF XML syntax.
>>
>> <f:view xmlns="http://www.w3.org/1999/xhtml"
>>         xmlns:f="http://java.sun.com/jsf/core"
>>         xmlns:h="http://java.sun.com/jsf/html">
>>   <html>
>>     <h:head><h:title>Title</h:title></h:head>
>>     <h:body>
>>
>>       <h2>HTML elements ok</h2>
>>
>>     </h:body>
>>   </html>
>> </f:view>
>>   
>
>
> While this is fine for cases where the page author wants to manually 
> insert an <f:view> tag, I still think that the fact that Facelets does 
> not require this is a nice perk.

I somewhat randomly stumbled across another problem with the above 
approach:  it doesn't work. :-(

The problem: when the default xhtml namespace is specified on <f:view>, 
this namespace does not get passed down to the browser.  As a result, 
the xhtml elements that the browser sees are not properly namespaced and 
the browser fails to handle these as xhtml elements.

This is yet another case where there is ambiguity regarding the role of 
an XML construct - ie. a namespace specified in a Facelets document 
clearly applies to the document itself  but could (and in this 
particular case should) also apply to the rendered content.

Of course, the following approach works just fine:

> <f:view xmlns:f="http://java.sun.com/jsf/core"
>              xmlns:h="http://java.sun.com/jsf/html">
>   <html xmlns="http://www.w3.org/1999/xhtml"> 

In this case Facelets passes the default namespace through to the 
browser along with the <html> element.

While this is a fine workaround, I am concerned that such dramatically 
different behavior in response to such a small/subtle difference in the 
view definition is bad for our end users.

I don't know that this is a spec issue (other than making sure that the 
spec does not contain references to the above broken form), but thought 
this was worth raising here as this likely affects all JSF/Facelets 
implementations.  I don't know the Faclets compiler code especially 
well, but I am wondering whether it could do some bookkeeping to 
detect/work around cases like this where default namespaces should in 
fact be propagated down to the browser.  Or, alternatively, perhaps a 
solution could be implemented at the ResponseWriter level, though it 
might be better to catch/correct this sort of thing earlier (Facelets 
compilation time) rather than later (render response).

Thoughts?  Do folks think that I should log implementation bugs and/or a 
spec issue for this?

Andy