Re: [jsr-314-open] Facelets: XHTML vs. XML

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