Gang - I have been think about the Dan's blog entry on Facelets pages as valid XML documents: http://blog.hibernate.org/10752.lace Actually, I have been struggling with related issues. Wanted to ping the EG to see whether we can start some discussion on this topic. In Dan's case, XML (plus XSD) provides a way to improve the page authoring experience. In my case, I am interested in XML as a way to support content-type independence for contents rendered by Faces components. That is, it should be possible to use Facelets as an XML document that describes how to build the component tree and leave the decision of whether to render XHTML content or HTML content (or some other type of content) up to the render kit. While Facelets is fairly close to meeting this requirement, there are a couple of minor assumptions built into the Facelets implementations (both Facelets 1.x and JSF 2.0) that complicate matters. The complications arise from how Facelets treats XML-specific constructs such as: - The XML declaration - XML processing instructions - CDATA sections Currently these constructs are doing double-duty: 1. They are consumed by the Facelets XML parser. 2. They are passed through to the browser. I suppose that #2 makes sense if you view the Facelets page as an XHTML document to which some pre-processing is applied before handing off to the client. However, this subverts the ability to support non-XML/XHTML content generation, such as HTML content generation. A simple example that demonstrates where we run into trouble... In ADF Faces applications, the root component (under the view root) is typically an af:document component. af:document takes care of rendering the document "chrome", including the doctype and the html/head/body elements. A minimal ADF Faces page might look something like this: <?xml version='1.0' encoding='utf-8'?> <f:view xmlns:f="http://java.sun.com/jsf/core" xmlns:af="http://xmlns.oracle.com/adf/faces/rich"> <af:document/> </f:view> This creates a trivial component tree: a UIViewRoot containing an ADF Faces RichDocument component. It should be possible to render this component tree as either an XHTML or an HTML document. The Renderer for the RichDocument component could easily handle both of these cases. However, there is a stumbling block... With Facelets, the XML declaration ends up being passed through to the browser, regardless of what type of content the RenderKit happens to generate. The end result: when rendering the document to HTML, we end up with a bogus XML declaration in our generated HTML content. In the above example, the purpose of including the XML declaration in the Facelets page is to ensure that the Facelets page is a valid XML document (#1 above), not for the purpose of including this in the generated content (#2 above), yet we end up with both. We run into similar problems with CDATA sections. For example, the following code uses the Trinidad trh:script component to insert a script into the page: <trh:script> <![CDATA[ if (0 < 1) alert("Woohoo! Zero *is* less than one!"); ]]> </trh:script> As with the previous example, the XML-specific construct (a CDATA section in this example) is meant to apply to the Facelets page itself - not to the generated content. That is, the CDATA section provides a way to tell the Facelets parser not to parse the specified character data. This is not intended to be used as an instruction to the browser (just to Facelets XML parser). However, Facelets passes the CDATA through to the browser. As a result, in the case where we render HTML content, we end up with bogus CDATA sections inside of our generated HTML document, which causes the browsers to get confused. In order to support content independence (or, more particularly, to support HTML rendering), the render kit needs to be able to make decisions such as whether script contents need to be wrapped in CDATA sections (when generating XHTML content yes, HTML content no) or whether an XML declaration is necessary in the generated content (same deal). Note that this sort of content-type independence is already possible using JSP documents (ie. XML-based JSP pages), since JSP engines interpret the XML constructs as instructions for the JSP's XML parser. There is no assumption that the generated output will be XML/XHTML. We would like to see Facelets support similar behavior. Of course, every Facelets page that currently exists relies on the current XHTML-centric behavior, so there is no chance that we can change this default behavior. However, I would like to see some mechanism for opting in to a more XML-centric processing model. I suppose that this could be left up to the JSF implementations to provide, though it seems like this might be a reasonable candidate for a spec-level solution. Thoughts? Andy

you can ommit the xml-declaration being passed through by using ui:composition: <?xml version='1.0' encoding='utf-8'?> <ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"> xmlns:f="http://java.sun.com/jsf/core" xmlns:af="http://xmlns.oracle.com/adf/faces/rich"> <f:view> <af:document/> </f:view> </ui:composition>

(other issues still remain though) regards, Norbert Andy Schwartz schrieb: > Gang - > > I have been think about the Dan's blog entry on Facelets pages as valid > XML documents: > > http://blog.hibernate.org/10752.lace > > Actually, I have been struggling with related issues. Wanted to ping > the EG to see whether we can start some discussion on this topic. > > In Dan's case, XML (plus XSD) provides a way to improve the page > authoring experience. In my case, I am interested in XML as a way to > support content-type independence for contents rendered by Faces > components. That is, it should be possible to use Facelets as an XML > document that describes how to build the component tree and leave the > decision of whether to render XHTML content or HTML content (or some > other type of content) up to the render kit. While Facelets is fairly > close to meeting this requirement, there are a couple of minor > assumptions built into the Facelets implementations (both Facelets 1.x > and JSF 2.0) that complicate matters. > > The complications arise from how Facelets treats XML-specific constructs > such as: > > - The XML declaration > - XML processing instructions > - CDATA sections > > Currently these constructs are doing double-duty: > > 1. They are consumed by the Facelets XML parser. > 2. They are passed through to the browser. > > I suppose that #2 makes sense if you view the Facelets page as an XHTML > document to which some pre-processing is applied before handing off to > the client. However, this subverts the ability to support non-XML/XHTML > content generation, such as HTML content generation. > > A simple example that demonstrates where we run into trouble... In ADF > Faces applications, the root component (under the view root) is > typically an af:document component. af:document takes care of rendering > the document "chrome", including the doctype and the html/head/body > elements. A minimal ADF Faces page might look something like this: > > <?xml version='1.0' encoding='utf-8'?> > <f:view xmlns:f="http://java.sun.com/jsf/core" > xmlns:af="http://xmlns.oracle.com/adf/faces/rich"> > <af:document/> > </f:view> > > This creates a trivial component tree: a UIViewRoot containing an ADF > Faces RichDocument component. It should be possible to render this > component tree as either an XHTML or an HTML document. The Renderer for > the RichDocument component could easily handle both of these cases. > > However, there is a stumbling block... With Facelets, the XML > declaration ends up being passed through to the browser, regardless of > what type of content the RenderKit happens to generate. The end result: > when rendering the document to HTML, we end up with a bogus XML > declaration in our generated HTML content. > > In the above example, the purpose of including the XML declaration in > the Facelets page is to ensure that the Facelets page is a valid XML > document (#1 above), not for the purpose of including this in the > generated content (#2 above), yet we end up with both. > > We run into similar problems with CDATA sections. For example, the > following code uses the Trinidad trh:script component to insert a script > into the page: > > <trh:script> > <![CDATA[ > if (0 < 1) alert("Woohoo! Zero *is* less than one!"); > ]]> > </trh:script> > > As with the previous example, the XML-specific construct (a CDATA > section in this example) is meant to apply to the Facelets page itself - > not to the generated content. That is, the CDATA section provides a way > to tell the Facelets parser not to parse the specified character data. > This is not intended to be used as an instruction to the browser (just > to Facelets XML parser). However, Facelets passes the CDATA through to > the browser. As a result, in the case where we render HTML content, we > end up with bogus CDATA sections inside of our generated HTML document, > which causes the browsers to get confused. > > In order to support content independence (or, more particularly, to > support HTML rendering), the render kit needs to be able to make > decisions such as whether script contents need to be wrapped in CDATA > sections (when generating XHTML content yes, HTML content no) or whether > an XML declaration is necessary in the generated content (same deal). > Note that this sort of content-type independence is already possible > using JSP documents (ie. XML-based JSP pages), since JSP engines > interpret the XML constructs as instructions for the JSP's XML parser. > There is no assumption that the generated output will be XML/XHTML. We > would like to see Facelets support similar behavior. > > Of course, every Facelets page that currently exists relies on the > current XHTML-centric behavior, so there is no chance that we can change > this default behavior. However, I would like to see some mechanism for > opting in to a more XML-centric processing model. I suppose that this > could be left up to the JSF implementations to provide, though it seems > like this might be a reasonable candidate for a spec-level solution. > > Thoughts? > > Andy > >

On Sat, May 9, 2009 at 4:00 PM, David Geary <clarity.training(a)gmail.com&gt;wrote: > 2009/5/7 Norbert Truchsess <norbert.truchsess(a)t-online.de&gt; > >> you can ommit the xml-declaration being passed through by using >> ui:composition: >> >> <?xml version='1.0' encoding='utf-8'?> >> <ui:composition xmlns:ui="http://java.sun.com/jsf/facelets"> >> xmlns:f="http://java.sun.com/jsf/core" >> xmlns:af="http://xmlns.oracle.com/adf/faces/rich"> >> <f:view> >> <af:document/> >> </f:view> >> </ui:composition> > > > Yes, and this should be a recommended practice, should it not? > > However, the preceeding fragment is XML, not XHTML. If you have a view > implemented as a composition, and you reference it as an action of a button > or link, the corresponding file must have a .xhtml extension, or the > navigation handler won't find it. IOW... > > <h:commandButton ... action="welcome"/> > > ...means the navigation handler will look for welcome.xhtml. If you name > the file welcome.xml, you get an error message at runtime. But if > welcome.xhtml uses a composition, like the preceeding code fragment, it's > not an XHTML file, it's XML. Ugh. > > Should the navigation handler also look for welcome.xml, or is that too > naiive of a fix? > Why don't you just make the javax.faces.DEFAULT_SUFFIX .xml?

I suppose you want to have a gradual migration.

priority order. I guess that is something an impl could provide (since migrations are something that you might look to a vendor to help you solve). The spec should assume you are using a single type (I guess).

-Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

Should the navigation handler also look for welcome.xml, or is that too naiive of a fix? Why don't you just make the javax.faces.DEFAULT_SUFFIX .xml? I thought about that, but it begs the question: why is the default suffix .xhtml to begin with? Shouldn't it really be XML? That's what I've been trying to say all along. I don't know why we don't just adopt the suffix .view.xml. We could just do .xml, but I fear that would seem a bit too generic. Either way, though, would at least get us away from this notion that the templates are XHTML, which they are not. They *sometimes* produce XHTML, but I have found them to also be very good for producing RSS and ATOM feeds. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.

Hi Andy, one more issue which _always_ comes up with people working with facelets and of course also stems from the same root-cause is the comment-problem - how can you correctly have comments for facelets and comments for the output? The way we currently do this is either set SKIP_COMMENTS to true - which effectively disallows HTML comments - or use ui:remove to make parts of the page Facelets-comments. However, the second approach doesn't allow invalid XML-snippets inside the ui:remove section - and this can be a very annoying thing then. Maybe it would be better to set SKIP_COMMENTS to true by default - and then have an <h:outputComment> for emitting HTML comments (I believe the problem of invalid XML in HTML-comments is not as big as in comments which are meant to be there for facelets).