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

[Dan Allen]

On Sat, Dec 12, 2009 at 11:28 PM, Martin Marinschek
<mmarinschek at apache.org>wrote:

> Hi guys,
>
> Right, but that's the leaky abstraction. We've more or less standardized
>> (it is the default extension, after all) on .xhtml, but XHTML is not
>> extensible. So let's just call it what it is, XML.
>>
>> Of course, I recognize that we can send other things to the browser. In
>> Seam we send e-mails, create PDFs, create RSS, create images, and create
>> excel documents. The point I'm making is that if the source document can
>> transform, then the most logical thing to call the source is XML, not XHTML.
>> The later implies some relationship with a particular variety of XML, and
>> specially one that browsers consume, confusing the whole matter.
>>
>>
>>>
>>> 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).
>>>
>>> Rename the extension. :)  Does that help?  j/k
>>>
>>
>> It does, quite a lot. But it needs to be official, not just a personal
>> change that is made in development.
>>
>>
>>>
>>> I'd like to understand what benefit we're getting by adding more
>>> complexity (proposed below) and potentially taking a performance hit
>>> (although perhaps some of the schema stuff can be turned off).  Perhaps it's
>>> worth it.  But as a non-IDE guy, I'm struggling to see just how much (if
>>> any) value this adds.  Are the benefits theoretical?  Are they material?
>>> Does is speed development for the end user, or just make us sleep better at
>>> night knowing we can call it true XML?  I'm not against anything proposed
>>> here, but at the same time I don't feel like I understand that value-add
>>> we're shooting for.  Can someone please take the time to explain the pros
>>> (and possibly cons) of the proposed changes?  From what I gather, it's all
>>> for the benefit of leveraging existing tools?
>>>
>>
>> Understand that first and foremost, this is a semantic change. It is an
>> acknowledgement, by the spec, that the source documents are just XML.
>> Nothing more. I can't see there being any performance change and probably a
>> minial implementation change. What will get fixed almost immediately are the
>> problems we are having with doctype declarations, XML declarations and
>> CDATA, because we are getting source and output mixed up right now. The XML
>> should describe what should be produced, not just pass through stuff these
>> critical aspects of the output.
>>
>> My point about the XSD is an add-on, of course. You don't have to have it,
>> but it will sure benefit people with XML editors a whole bunch. The point
>> is, if we treat these documents as XML documents, and not some strange
>> hybrid of XHTML and XML component tags, then we can leverage all the
>> existing XML tools on the planet to edit, transform and interpret these
>> documents. When I type "vim home.xhtml" it just doesn't work like if I typed
>> "vim home.view.xml". It makes a difference.
>>
>
> I agree with the notion of having a .xml extension for Facelets pages, and
> also with not passing the meta-data to the output. I think the performance
> hit is minimal, and it definitely brings us one step up the abstraction
> ladder. However, I want this to be optional - you should be allowed to be
> both. While Jacob did say on his blog not to mix the two things, he still
> had this jsfc-feature in Facelets, cause some people don´t want/need to
> abstract away from XHTML. And I believe we should keep it like this for the
> small and simple project (cause if we face it, passing the metadata with a
> new set of components is additional complexity which we don´t need for the
> simple case).
>
> Martin, you raise a really good point! 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. You would need a specific doctype element to push to the browser.

Here's how the formal XML syntax would look (with our new URN namespaces ;))

<?xml version="1.0" encoding="UTF-8"?>
<f:view xmlns:f="jsf:core" xmlns:h="jsf:html" omitXmlDeclaration="true">
   <h:doctype lang="xhtml" type="strict"/>
   <h:html>
      <h:head>
      </h:head>
      <h:body>
        <h1>Hello World!</h1>
      </h:body>
   </h:html>
</f:view>

We are really only talking about the addition of two tags, h:html and
h:doctype (and really, h:html isn't event really required). And right now,
how doctype is handled is so confusing that this would be much more clear.

Btw, omitXmlDeclaration would probably be true by default (or basically, we
do the thing that is the 80% case).

There is also the possibility that instead of doing h:html, we do something
like f:document and it creates the correct root tag based on the renderkit,
we need to talk more about that.

-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/20091213/60c19784/attachment.html