2009/5/7 Norbert Truchsess <span dir="ltr"><<a href="mailto:norbert.truchsess@t-online.de">norbert.truchsess@t-online.de</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
you can ommit the xml-declaration being passed through by using<br>
ui:composition:<br>
<div class="im"><br>
<?xml version='1.0' encoding='utf-8'?><br>
</div><ui:composition xmlns:ui="<a href="http://java.sun.com/jsf/facelets" target="_blank">http://java.sun.com/jsf/facelets</a>"><br>
<div class="im"> xmlns:f="<a href="http://java.sun.com/jsf/core" target="_blank">http://java.sun.com/jsf/core</a>"<br>
xmlns:af="<a href="http://xmlns.oracle.com/adf/faces/rich" target="_blank">http://xmlns.oracle.com/adf/faces/rich</a>"><br>
</div> <f:view><br>
<af:document/><br>
</f:view><br>
</ui:composition></blockquote><div><br>Yes, and this should be a recommended practice, should it not? <br><br>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..<br>
<br><h:commandButton ... action="welcome"/><br><br>...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.<br>
<br>Should the navigation handler also look for welcome.xml, or is that too naiive of a fix? <br><br><br>david<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
(other issues still remain though)<br>
<br>
regards,<br>
<br>
Norbert<br>
<br>
Andy Schwartz schrieb:<br>
<div><div></div><div class="h5">> Gang -<br>
><br>
> I have been think about the Dan's blog entry on Facelets pages as valid<br>
> XML documents:<br>
><br>
> <a href="http://blog.hibernate.org/10752.lace" target="_blank">http://blog.hibernate.org/10752.lace</a><br>
><br>
> Actually, I have been struggling with related issues. Wanted to ping<br>
> the EG to see whether we can start some discussion on this topic.<br>
><br>
> In Dan's case, XML (plus XSD) provides a way to improve the page<br>
> authoring experience. In my case, I am interested in XML as a way to<br>
> support content-type independence for contents rendered by Faces<br>
> components. That is, it should be possible to use Facelets as an XML<br>
> document that describes how to build the component tree and leave the<br>
> decision of whether to render XHTML content or HTML content (or some<br>
> other type of content) up to the render kit. While Facelets is fairly<br>
> close to meeting this requirement, there are a couple of minor<br>
> assumptions built into the Facelets implementations (both Facelets 1.x<br>
> and JSF 2.0) that complicate matters.<br>
><br>
> The complications arise from how Facelets treats XML-specific constructs<br>
> such as:<br>
><br>
> - The XML declaration<br>
> - XML processing instructions<br>
> - CDATA sections<br>
><br>
> Currently these constructs are doing double-duty:<br>
><br>
> 1. They are consumed by the Facelets XML parser.<br>
> 2. They are passed through to the browser.<br>
><br>
> I suppose that #2 makes sense if you view the Facelets page as an XHTML<br>
> document to which some pre-processing is applied before handing off to<br>
> the client. However, this subverts the ability to support non-XML/XHTML<br>
> content generation, such as HTML content generation.<br>
><br>
> A simple example that demonstrates where we run into trouble... In ADF<br>
> Faces applications, the root component (under the view root) is<br>
> typically an af:document component. af:document takes care of rendering<br>
> the document "chrome", including the doctype and the html/head/body<br>
> elements. A minimal ADF Faces page might look something like this:<br>
><br>
> <?xml version='1.0' encoding='utf-8'?><br>
> <f:view xmlns:f="<a href="http://java.sun.com/jsf/core" target="_blank">http://java.sun.com/jsf/core</a>"<br>
> xmlns:af="<a href="http://xmlns.oracle.com/adf/faces/rich" target="_blank">http://xmlns.oracle.com/adf/faces/rich</a>"><br>
> <af:document/><br>
> </f:view><br>
><br>
> This creates a trivial component tree: a UIViewRoot containing an ADF<br>
> Faces RichDocument component. It should be possible to render this<br>
> component tree as either an XHTML or an HTML document. The Renderer for<br>
> the RichDocument component could easily handle both of these cases.<br>
><br>
> However, there is a stumbling block... With Facelets, the XML<br>
> declaration ends up being passed through to the browser, regardless of<br>
> what type of content the RenderKit happens to generate. The end result:<br>
> when rendering the document to HTML, we end up with a bogus XML<br>
> declaration in our generated HTML content.<br>
><br>
> In the above example, the purpose of including the XML declaration in<br>
> the Facelets page is to ensure that the Facelets page is a valid XML<br>
> document (#1 above), not for the purpose of including this in the<br>
> generated content (#2 above), yet we end up with both.<br>
><br>
> We run into similar problems with CDATA sections. For example, the<br>
> following code uses the Trinidad trh:script component to insert a script<br>
> into the page:<br>
><br>
> <trh:script><br>
> <![CDATA[<br>
> if (0 < 1) alert("Woohoo! Zero *is* less than one!");<br>
> ]]><br>
> </trh:script><br>
><br>
> As with the previous example, the XML-specific construct (a CDATA<br>
> section in this example) is meant to apply to the Facelets page itself -<br>
> not to the generated content. That is, the CDATA section provides a way<br>
> to tell the Facelets parser not to parse the specified character data.<br>
> This is not intended to be used as an instruction to the browser (just<br>
> to Facelets XML parser). However, Facelets passes the CDATA through to<br>
> the browser. As a result, in the case where we render HTML content, we<br>
> end up with bogus CDATA sections inside of our generated HTML document,<br>
> which causes the browsers to get confused.<br>
><br>
> In order to support content independence (or, more particularly, to<br>
> support HTML rendering), the render kit needs to be able to make<br>
> decisions such as whether script contents need to be wrapped in CDATA<br>
> sections (when generating XHTML content yes, HTML content no) or whether<br>
> an XML declaration is necessary in the generated content (same deal).<br>
> Note that this sort of content-type independence is already possible<br>
> using JSP documents (ie. XML-based JSP pages), since JSP engines<br>
> interpret the XML constructs as instructions for the JSP's XML parser.<br>
> There is no assumption that the generated output will be XML/XHTML. We<br>
> would like to see Facelets support similar behavior.<br>
><br>
> Of course, every Facelets page that currently exists relies on the<br>
> current XHTML-centric behavior, so there is no chance that we can change<br>
> this default behavior. However, I would like to see some mechanism for<br>
> opting in to a more XML-centric processing model. I suppose that this<br>
> could be left up to the JSF implementations to provide, though it seems<br>
> like this might be a reasonable candidate for a spec-level solution.<br>
><br>
> Thoughts?<br>
><br>
> Andy<br>
><br>
><br>
</div></div></blockquote></div><br>