3:21 p.m.
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