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

[Martin Marinschek]

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).

regards,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20091213/23a5b0a8/attachment.html