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

Mon Oct 18 17:25:25 EDT 2010

Ed, All -

I have finally started reviewing the pdf, including the new chapter 11: 
"The JSF XML View Syntax".  Unfortunately, while reviewing this chapter 
I felt very lost.

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

I didn't realize that we were introducing a new VDL.  I thought that our 
efforts have been focused on allowing the existing Facelets VDL to be 
more XML-friendly by providing control over XML processing behavior.

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

The differences that we have been discussing between legacy 
xhtml-centric Facelets and the new xml-centric approach are related to 
processing of XML-centric constructs such as CDATA blocks, XML 
declarations, processing instructions, etc...  I didn't realize that we 
would also be changing how HTML template text/tags were handled.  If 
this means that you cannot use HTML elements in the new XML views, my 
guess is that nobody will be interested in adopting this approach.

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

One small but important feature that folks seemed to like about Facelets 
is that it made the <f:view> optional.  If we now require a new 
top-level element, my guess is that many people will find this to be a 
step backwards.

I find section 11.2, "Java Programming Language Specification for Faces 
XML Views" to be overly detailed and difficult to read, eg:

> Each element in the XML view falls into one of the following 
> categories, each of which corresponds to an instance of a Java object 
> that implements javax.faces.view.facelets.FaceletHandler, or a 
> subinterface or subclass thereof, and an instance of 
> javax.faces.view.facelets.TagConfig, or a subinterface or subclass 
> thereof, which is passed to the constructor of the object implementing 
> FaceletHandler.The mapping between the categories of elements in the 
> XML view and the appropriate subinterface or subclass of 
> FaceletHandler is specified below. Each FaceletHandler instance must 
> be traversed and its apply() method called in the same depth-first 
> order as in the other lifecycle phase methods in jsf. Each 
> FaceletHandler instance must use the getNextHandler() method of the 
> TagConfig instance passed to its constuctor to perform the traversal 
> starting from the root FaceletHandler.

I am surprised that we need to go into this level of detail.  Perhaps 
the problem is that I am not a JSF implementor and as such I don't 
appreciate why this sort of detail is necessary.  I also worry that this 
is information that must be available elsewhere (eg. for the Facelets 
VDL), in which case we don't have a single source of truth.

Could the MyFaces guys comment on whether this level of detail in 
section 11.2 is helpful to you as JSF implementors?

The big picture problem that I have with the information in chapter 11 
is that I do not understand how this relates to xhtml/xml/facelets 
processing mode that we have been discussing in detail over the last few 
weeks.  I did not realize that a new VDL was necessary.  I thought that 
our focus was on configuring how Facelets processes documents that are 
mapped to the Facelets VDL.

I would prefer that we focus on the approach that is currently outlined 
in Apendix A, section 1.2.1.1 ("The facelets-processing element") and 
avoid introducing a new VDL as described in chapter 11.

BTW, if we are introducing a new VDL, one thing that is missing is any 
mention of how to map views to this VDL - ie. there is no equivalent of 
the javax.faces.FACELETS_VIEW_MAPPINGS.  Though based on the concerns 
that Leonardo raised on our other active thread, rather than introduce 
additional context parameters for this sort of thing, we should look 
into a generic faces-config-based VDL registration mechanism.

Andy