On Mon, Dec 14, 2009 at 1:46 PM, Simon Lessard <Simon_Lessard(a)dmr.ca> wrote:
Well, 2 reasons:
1. It's along the line of Dan suggestion about Facelet and not pushing
direct html to the output, a different render kit might have to intercept
the ResponseWriter to tranform some of those new tags to something else. New
tags allow just that, giving the opportunity to encode the view in just
about anything. Maybe a PADF render kit using iText (althoguh that one could
deal with the HTML), or renderer generating TeX, that in turn gets turned to
PDF using some of the available engines in the endDocument call.
2. Most importantly, semantic and accessibility. A view remains a document
and providing every basic components in the HTML kit enhance that toolbox
and allows developer to add whetever they want to their view, really
expressing what is ment to be there. I'm prety sure this would also come
(especialy?) handy in composite componnet development. As for the
accessibility part, <p> != <div> != <fielset> for a screenreader or
any
other accessibility enabled device. As for the header, we could provide
auto-depth detection if not overriden using a level/depth attribute. In
pretty much all project I had to work on we had to redevelop pretty much all
those components because Facelets was not an option at the time (and
Facelets would have been to HTML coupled anyway).
The topic in this thread is bleeding slightly into the "Facelets is XML"
thread. I want to clarify that by requesting to have the Facelets template
treated as a generic XML document, I'm not suggesting that we fill the
entire XML document with component tags. That would be throwing away the
most useful feature of Facelets, which is to wrap and output inline XML
markup. My point is that the inline markup is not necessarily XHTML, it is
just some XML langauge, which most of the time happens to be in the HTML
family.
I recognize that every template is likely going to be fairly render-kit
specific. The point I'm making is that the Facelets XML language *itself*
should not be trying to act like XHTML (and sending headers and CDATA it
shouldn't be sending).
-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