Re: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Namespace handling [Was: Chapter 11: The JSF XML View Syntax]
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