[jsr-314-open-mirror] [jsr-314-open] [490-XmlViews] Chapter 11: The JSF XML View Syntax

Tue Oct 19 13:06:39 EDT 2010

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 at 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/>
                    &amp;lt;context-param&amp;gt;
                    <br/>

&amp;nbsp;&amp;nbsp;&amp;lt;param-name&amp;gt;javax.faces.PARTIAL_STATE_SAVING 

&amp;lt;/param-name&amp;gt;
                    <br/>

&amp;nbsp;&amp;nbsp;&amp;lt;param-value&amp;gt;true&amp;lt;/param-value&amp;gt 

;
                    <br/>
                    &amp;lt;/context-param&amp;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 at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
| 16 work days until German Oracle User's Group Conference