12:06 p.m.
Executive Summary:
* Andy comments on the new Chapter 11, basically stating that we don't
need it.
* Ed replies stating that that Dan had requested full XML syntax, but
that Ed is willing to remove chapter 11 for now and simply rely on
what we have in the appendix regarding the facelets-processing elemens
in the faces-config-extension element.
>>>> On Mon, 18 Oct 2010 17:25:25 -0400, Andy Schwartz
<andy.schwartz(a)oracle.com> said:
AS> Ed, All -
AS> I have finally started reviewing the pdf, including the new chapter 11:
AS> "The JSF XML View Syntax". Unfortunately, while reviewing this chapter
AS> I felt very lost.
AS> The chapter opens with:
> As of version 2.1 of this specification, JavaServer Faces
> implementations must support (although JSF-based applications need not
> utilize) using plain XML as a View Declaration Language (VDL).
AS> I didn't realize that we were introducing a new VDL. I thought that our
AS> efforts have been focused on allowing the existing Facelets VDL to be
AS> more XML-friendly by providing control over XML processing behavior.
This is what Dan Allen has wanted all along. It was very clearly stated
in his requests and emails to this list.
> The main difference between using XML as a VDL and using Facelets
is
> that the XML syntax does not support HTML template text. In other
> words, every element in a facelets XML page must be a JSF UI
> component. There is no facility for automatically generating transient
> UIComponent instances from template text. If you want this facility,
> use Facelets as your VDL.
AS> The differences that we have been discussing between legacy
AS> xhtml-centric Facelets and the new xml-centric approach are related to
AS> processing of XML-centric constructs such as CDATA blocks, XML
AS> declarations, processing instructions, etc... I didn't realize that we
AS> would also be changing how HTML template text/tags were handled. If
AS> this means that you cannot use HTML elements in the new XML views, my
AS> guess is that nobody will be interested in adopting this approach.
I thought so too, but that seems to be what Dan wanted so that's what I
put in the spec.
> First note the outer-most <faces-view> element. In
Facelets, the
> outer-most element is normally the <html> element. In Facelets, the
> <html> element is where the taglibs used in the page are declared. In
> the Faces XML VDL, the <faces-view> element is the outer-most element
> and here is where the taglibs used are declared.
AS> One small but important feature that folks seemed to like about Facelets
AS> is that it made the <f:view> optional. If we now require a new
AS> top-level element, my guess is that many people will find this to be a
AS> step backwards.
I'm certainly open to dropping this requirement. In fact, I have
modified Mojarra so that you can have the following as valid
jsf.view.xml syntax.
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:head><h:title>Raw XML View</h:title></h:head>
<h:body>
<h2>XML declaration: consumed</h2>
<h2>Processing instruction: consumed</h2>
<?xml-stylesheet href="funky.xsl" type="text/xml"
alternate="yes"?>
<h2>CDATA section: consumed</h2>
<![CDATA[ <p>This is CDATA</p> ]]>
<h2>Inline text escaping: escaped</h2>
<code>
<br/>
&lt;context-param&gt;
<br/>
&nbsp;&nbsp;&lt;param-name&gt;javax.faces.PARTIAL_STATE_SAVING
&lt;/param-name&gt;
<br/>
&nbsp;&nbsp;&lt;param-value&gt;true&lt;/param-value&gt
;
<br/>
&lt;/context-param&gt;
</code>
<h2>Comments: consumed</h2>
<!-- comments consumed -->
<h:form prependId="false" id="form">
<h:panelGrid id="grid" column="2">
<h:outputText id="text"
value="hello"></h:outputText>
<h:commandButton id="button"
value="reload"></h:commandButton>
</h:panelGrid>
#{processAsJspxBean.prop}
<p>html template text</p>
</h:form>
</h:body>
</html>
AS> I find section 11.2, "Java Programming Language Specification for Faces
AS> XML Views" to be overly detailed and difficult to read, eg:
[...]
AS> I would prefer that we focus on the approach that is currently outlined
AS> in Apendix A, section 1.2.1.1 ("The facelets-processing element") and
AS> avoid introducing a new VDL as described in chapter 11.
AS> BTW, if we are introducing a new VDL, one thing that is missing is any
AS> mention of how to map views to this VDL - ie. there is no equivalent of
AS> the javax.faces.FACELETS_VIEW_MAPPINGS. Though based on the concerns
AS> that Leonardo raised on our other active thread, rather than introduce
AS> additional context parameters for this sort of thing, we should look
AS> into a generic faces-config-based VDL registration mechanism.
Unless anyone disagrees, I'll remove chapter 11, perhaps we can revisit
this at such time as JBoss is able to contribute again to these
discussions.
Ed
--
| edward.burns(a)oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 16 work days until German Oracle User's Group Conference
12:37 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
On 10/19/10 1:06 PM, Ed Burns wrote:
Executive Summary:
* Andy comments on the new Chapter 11, basically stating that we don't
need it.
Yep.
* Ed replies stating that that Dan had requested full XML syntax,
but
that Ed is willing to remove chapter 11 for now and simply rely on
what we have in the appendix regarding the facelets-processing elemens
in the faces-config-extension element.
Works for me. :-)
AS> I didn't realize that we were introducing a new VDL. I
thought that our
AS> efforts have been focused on allowing the existing Facelets VDL to be
AS> more XML-friendly by providing control over XML processing behavior.
This is what Dan Allen has wanted all along. It was very clearly stated
in his requests and emails to this list.
Although I followed/participated in these threads and discussed with Dan
multiple times in person, I never realized that he was pushing for a new
VDL. I always thought that this was about making Facelets more
XML-friendly as opposed to replacing Facelets with a new VDL. Ah well,
I suppose either approach can work, though personally I prefer sticking
with Facelets as our main VDL.
AS> The differences that we have been discussing between legacy
AS> xhtml-centric Facelets and the new xml-centric approach are related to
AS> processing of XML-centric constructs such as CDATA blocks, XML
AS> declarations, processing instructions, etc... I didn't realize that we
AS> would also be changing how HTML template text/tags were handled. If
AS> this means that you cannot use HTML elements in the new XML views, my
AS> guess is that nobody will be interested in adopting this approach.
I thought so too, but that seems to be what Dan wanted so that's what I
put in the spec.
Hrm.... I thought that Dan stated the opposite of this. Looking back at
Dan's original "[jsf2next] might as well face it, Facelets is XML" email
(12/11/09), I see these recommendations:
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!
The second #2 :-) says: "verbatim content can still be wrapped
automatically as UIInstruction fragments, that does work", which
contradicts the behavior specified in Chapter 11.
Unless anyone disagrees, I'll remove chapter 11, perhaps we can
revisit
this at such time as JBoss is able to contribute again to these
discussions.
Sounds good. Our recent changes address Dan's #1, both #2s and parts of
#3. Seems like a good start for 2.1. We can do more in future spec
revs, hopefully with the involvement of our JBoss friends. :-)
Andy
Ed
1:32 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
Hi guys,
just wanted to note that after carefully reading through this thread,
I completely agree with Andy, and with Ed's conclusion of removing
chapter 11. We should definitely not define a new VDL, and even if we
did, we should certainly not disallow passing arbitrary text through
to the response: this would effectively kill off this new VDL right
away, just like JSP as a VDL was killed off by exactly this problem.
I also agree that the level of detail in the section Andy pointed to
would not be needed.
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
9:23 p.m.
New subject: [jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax
As I had understood it, the need for XML was motivated by these usecases:
1) To allow developers to use standard XML processing tools. In
particular, this requires to be truthful about the nature of the
documents (i.e. not claim that something is an XHTML file when it
isn't, but is really an artifact that will eventually be transformed
into XHTML)
2) To not surprise developers with nonstandard XML processing (such as
processing comments).
There is, of course, no need for a new VDL, just a strict XML mode for facelets.
Cay
5069
days inactive
5072
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
4 participants
participants (4)
-
Andy Schwartz -
Cay Horstmann -
Ed Burns -
Martin Marinschek