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

[Kito Mann]

Interesting points, Andy. The fact that Facelets currently makes it
difficult to support non-XML documents is a little problematic...One would
expect to use Facelets to define only a component tree, with nothing passed
through; the render kit should decide how that component tree is displayed.
Moreover, loosing functionality that JSP provides is a bad thing.

If there's a simple, elegant solution, I vote for putting it in the
maintenance release.
---
Kito D. Mann -- Author, JavaServer Faces in Action
http://twitter.com/kito99  http://twitter.com/jsfcentral
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
+1 203-404-4848 x3


On Thu, May 7, 2009 at 4:21 PM, Andy Schwartz <andy.schwartz at oracle.com>wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090507/576e3ace/attachment.html