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

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>

(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 > >