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

[Andy Schwartz]

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