On Mon, Dec 14, 2009 at 5:23 PM, Andy Schwartz
<andy.schwartz@oracle.com> wrote:
Thanks Dan for getting this discussion going (again)!
Call it my crusade.
If the file extension is .xhtml, then perhaps we can have it use the existing pass-through behavior for convenience. But if the file extension is .view.xml (or whatever we settle on), then the XML declarations, schema declarations and doctype (though you shouldn't really have a doctype anymore) are for the XML template document itself.
Keep in mind, by "pass-through" I mean how literally does the Facelets engine rewrite the inline markup into the output. For instance, if CDATA is in the template, should CDATA be put in the output or should the contents of CDATA be put there (or ignored)? So it's really to what degree is the inline markup passed through.
This approach would be perfect for my use case. One of the reasons why I am interested in pushing this XML view of the world is because I am already using a technology that supports this: JSP documents - ie. XML-based JSP pages. (Funny, yes, there is something about JSP that I actually like more than Facelets!) In our case we have a tremendous amount of XML-based JSF content sitting around in .jspx files. (We also use the extension .jsff for "JSF fragments" - ie. files that specify component subtrees rather than complete pages.) For the most part we can simply run these files via the Facelets engine. (Yet another reason why I love Facelets.) In JSP document land, XML instructions (the XML declaration, CDATA sections) are treated as instructions to the JSP engine itself
Yes, which is exactly what Facelets really should be. Cutting corners should be allowed (.xhtml), but staying on the path should be supported too (.view.xml).
This means that I can have the following .jspx file:
<?xml version='1.0' encoding='utf-8'?>
<f:view>
<tr:document>
<trh:script>
<![CDATA[
if (0 < 1) alert("w00t!");
]]>
</trh:script>
</tr:document>
</f:view>
And not have to worry about the XML declaration or CDATA section wrapper being sent to the browser. Instead, my render kit can decide to render an XML declaration or not (depending on whether we are generating XHTML or HTML), and the trh:script renderer can decide how to deal with its body. (The HTML <script> element is implicitly CDATA, so the script content can be passed directly through.)
+1
As we've been discussing, Facelets will pass this XML-specific content directly on to the browser, which is invalid in the case where we are rendering traditional HTML.
Exactly, this is where we get in trouble.
We have had to take steps to address this internally - ie. we have a patched version of Facelets 1.x that allows XML instruction handling to be controlled via a context parameter, similar to "facelets.SKIP_COMMENTS" However, this is gross - we really need a solution that is sanctioned by the spec and provided by the JSF implementations.
+10
Thus, a solution where the XML processing behavior is triggered by the file extension (ie. .xhtml preserves old behavior, new behavior elsewhere) would be a huge step forward for us.
I like this approach. We already have a nice separation established, since .xhtml producing HTML output is a logical relationship. Adding .view.xml makes people recognize that the output type is going to have to be more explicitly defined.
The changes that we ended up making to Facelets 1.x to support this (well, something like this - a context parameter approach) were trivial. If we can reach consensus on this solution (or something like it), I would be happy to provide a patch that implements this behavior.
Great!
FWIW, this issue is currently an obstacle to wider adoption of Facelets within Oracle, so I am very interested in seeing whether we can get some solution in place soon (ie. before 2.1). I would of course prefer a spec'ed solution, but could live with an implementation-specific solution if that is our only option in the short term.
And something that is an obstacle to adoption at Oracle should be taken seriously, guys. Because we are talking about a large market getting onto the Facelets and JSF 2.0 train.
Regarding:
3) All markup declarations should be produced by the component tree (e.g., XML declaration, doctype, namespaces, CDATA, XML comments, etc)
This means we need the following tags:
f:document
f:doctype
In Trinidad/ADF Faces we've combined these into a single "document" tag and let the RenderKit pick the doctype so that our page authors don't need to worry about this.
Right, the idea of the document is really that the renderkit can worry about getting the right headers sent. So some of these tags might not even be needed. We need to prototype some example templates and see which tags we feel are really needed.
f:comment (why not, it is just xml)
f:cdata
If we expose an f:cdata component, we'll need to understand what this means for HTML-based render kits.
It depends on how we intend on consuming CDATA. Again, we just need some example templates to determine which tags we really need. I'm just suggesting that when we have ambigous situations, the tags could explicitly define how the nested content should be handled.
Another thing to consider is how to handle entities. For a long time entities (like &) were a mess in Facelets. Now we have it where & in the template becomes & in the output. We have to think about whether that should be the case in the .view.xml (let's call it strict) mode. I would hate to have to write &amp; again. Yuk!
-Dan