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

[Martin Marinschek]

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).

regards,

Martin

On 5/7/09, 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
>
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces