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

[Dan Allen]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091211/04f6f259/attachment.html