[jsr-314-open] [jsf2next] might as well face it, Facelets is XML

[Andy Schwartz]

Gang -

I finally managed to read through this email thread.  Thanks Dan for 
getting this discussion going (again)!  As I mentioned in our original 
thread back in May, I am very interested in this problem as well.  I am 
happy with where this thread ended up - ie. I very much want to see an 
XML-centric approach, but I agree with Martin that we should continue to 
support the XHTML-centric approach as well.

Dan has already mentioned one way to accomplish this:

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

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.

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

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.

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.

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.

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.

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.

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.

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

Andy


Dan Allen wrote:
> On the panel at JSF Summit, when I said that my JSF hot button is view 
> metadata, I was wrong. The most important issue to me is seeing 
> Facelets reach maturity as an XML-based template language that 
> produces components, not XHTML.
>
> What Jacob did for JSF by introducing Facelets was nothing short of 
> miraculous. I personally believe that he saved JSF so that it was able 
> to survive until JSF 2.0 ;) But he did fall slightly short of making 
> Facelets perfect. The main problem is that he sat in limbo between an 
> XHTML-based template document that could cloak itself as a component 
> tree and an XML-based template language that could produce a component 
> tree and, in turn, response markup. We need to shift this final puzzle 
> piece into place.
>
> I'm going to go out on a limb here and say that Jacob choose XHTML for 
> two reasons:
>
> 1) He could throw a SAX parser at it and produce a component tree 
> (putting an end to the debacle that was JSP markup)
> 2) It would put an end to the debacle that was the <f:verbatim> tag 
> for rendering plain HTML, which was 80% of the page 80% of time.
>
> He saved us. (Too bad he wasn't there to receive the endless praise at 
> JSF Summit. That's what you get for going into management. People 
> praise your ghost.)
>
> However, he did one major disservice for JSF (No, Dan! How could you 
> criticize the King?) That's right, I said it. Somebody had to say it. 
> It had to be said. He violated the objective of JSF to support 
> multiple renderkits.
>
> We are more linked to HTML today than we have ever been before. Why do 
> I say that? Our view templates end in .xhtml, that's why. Okay, but 
> .xhtml is extensible, right? Wrong. XHTML is not an extensible 
> language (despite it's name). It is based on a closed doctype, which 
> we learned at Rich Web (the sibling conference to JSF Summit) is now 
> dead. So we are never going to see that extensibility.
>
> So we are using a document with an XHTML doctype, and XML declaration, 
> XML namespaces (which XHTML does not support), yet no XML schema to 
> back it. We are in serious limbo. Do you realize how strange it is to 
> use .xhtml to produce an ATOM feed? And we wonder why the tools are 
> having trouble supporting this (okay, NetBeans figured it out, but still).
>
> But, wait! XHMTL is useful because we can preview the template in a 
> browser, right? That's what the jsfc attribute is all about. We can 
> make an input component look like an HTML input.
>
> <input jsfc="h:input" id="name" value="#{user.name <http://user.name>}"/>
>
> Guess what? Jacob backed away from this almost as soon as he added it 
> to Facelets. It's a leaky abstraction and simply doesn't scale. It has 
> no practical application. In his words:
>
>     "It's just dumb to use 'jsfc' and 'jwcid'. Those two things would
>     be great if the semantics were the same between html and
>     components, but they aren't. And even if they do parallel, the
>     next concern is that there should be dummy content
>     for the designer to play with, you have to remove it. I say don't
>     even bother with it in the first place and stop expressing
>     concerns within the same document."
>
>
> http://hookom.blogspot.com/2005/09/more-on-programmer-pages.html
>
> As it turns out, I didn't even start this call to action. It was Jacob 
> after all!
>
> So how to we move forward? We have to accept these truths (well, some 
> are recommendations):
>
> 1) A Facelets document is XML, plain and simple
> 2) The extension for a Facelets document becomes .view.xml (DOT view 
> DOT xml)
> 2) A Facelets document produces a component tree; verbatim content can 
> still be wrapped automatically as UIInstruction fragments, that does work
> 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
> f:comment (why not, it is just xml)
> f:cdata
> (The prefix is debatable, I'm just throwing it out there)
>
> The markup declarations in the template DO NOT PASS THROUGH!
>
> 4) We can now use XSD to describe component library tags!!!! XSD is so 
> unbelievably powerful, let's use it!
>
> <?xml version="1.0" encoding="UTF-8"?>
> <f:view xmlns="http://www.w3.org/1999/xhtml"
>     xmlns:ui="http://java.sun.com/jsf/facelets"
>     xmlns:f="http://java.sun.com/jsf/core"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="
>         http://java.sun.com/jsf/facelets facelets-ui-2.1.xsd
>         http://java.sun.com/jsf/core jsf-core-2.1.xsd">
> </f:view>
>
> Of course, you only need the XSD stuff if you are looking for tooling 
> support. It is optional!
>
> Let's answer Jacob's call to action and stop expressiong concerns 
> within the same document.
>
> Issues:
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=697
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=489
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=490
>
> Blog entry:
> http://blog.hibernate.org/10752.lace
>
> Previous thread:
> http://archives.java.sun.com/cgi-bin/wa?A2=ind0905&L=jsr-314-open&F=&S=&X=40EFF100C4CB5F138F&P=922 
> <http://archives.java.sun.com/cgi-bin/wa?A2=ind0905&L=jsr-314-open&F=&S=&X=40EFF100C4CB5F138F&P=922>
>
> -Dan
>
> -- 
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen