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

[Dan Allen]

On Mon, Dec 14, 2009 at 5:23 PM, Andy Schwartz <andy.schwartz at 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 &amp;) were a mess in Facelets. Now we have it where &amp; in
the template becomes &amp; 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;amp; again. Yuk!

-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/20091215/d40a94cd/attachment.html