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}"/>

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

-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