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

[David Geary]

2009/5/7 Norbert Truchsess <norbert.truchsess at t-online.de>

> you can ommit the xml-declaration being passed through by using
> ui:composition:
>
> <?xml version='1.0' encoding='utf-8'?>
> <ui:composition xmlns:ui="http://java.sun.com/jsf/facelets">
>      xmlns:f="http://java.sun.com/jsf/core"
>     xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
>   <f:view>
>    <af:document/>
>  </f:view>
> </ui:composition>


Yes, and this should be a recommended practice, should it not?

However, the preceeding fragment is XML, not XHTML. If you have a view
implemented as a composition, and you reference it as an action of a button
or link, the corresponding file must have a .xhtml extension, or the
navigation handler won't find it. IOW...

<h:commandButton ... action="welcome"/>

..means the navigation handler will look for welcome.xhtml. If you name the
file welcome.xml, you get an error message at runtime. But if welcome.xhtml
uses a composition, like the preceeding code fragment, it's not an XHTML
file, it's XML. Ugh.

Should the navigation handler also look for welcome.xml, or is that too
naiive of a fix?


david


>
>
> (other issues still remain though)
>
> regards,
>
> Norbert
>
> Andy Schwartz schrieb:
> > 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/20090509/5f40176a/attachment-0001.html