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

Thu Oct 28 12:08:23 EDT 2010

I was thinking that this was an XHTML ResponseWriter thing.  It's not 
like the ResponseWriter doesn't know that nobody has output a prefix 
mapping for XHTML yet (ignoring the case where it was sent out through 
unescaped text and even then creating a new mapping isn't the end of the 
world as long as it doesn't conflict).

We will eventually have a bigger problem that the ResponseWriter 
interface allows no way to specify a namespace.  This is lame and I'm 
not a big fan of the workaround of abusing the default namespace or 
passing the prefixes in with the element names.

-- Blake Sullivan

On 10/28/10 8:54 AM, Andy Schwartz wrote:
> (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
>