[jsr-314-open-mirror] [jsr-314-open] JSF 2.1 Omnibus reply

Tue Oct 26 17:26:31 EDT 2010

On 10/26/10 4:13 PM, Ed Burns wrote:
> What are we doing with suffix/extension configuration:
>
> AS> - Enhance the DEFAULT_FACELETS_SUFFIX context parameter to allow it
> AS> to support multiple values + change the default value to ".xhtml
> AS> .view.xml".  Or...
>
> AS> - Specify a default value for the FACELETS_VIEW_MAPPINGS context
> AS> parameter.
>
> AS> Either of these seem acceptable to me.
>
> EB> I am reluctant to bind .view.xml to be "Facelets".  Yes, right now
> EB> Mojarra is using the Facelets VDL impl to process .view.xml but I'd
> EB> rather leave the DEFAULT_FACELETS_SUFFIX and FACELET_VIEW_MAPPINGS
> EB> unchanged for 2.1.

I find this confusing.  The DEFAULT_FACELETS_SUFFIX and 
FACELET_VIEW_MAPPINGS parameters control which views the Facelets VDL 
will handle.  How does Mojarra determine that the Facelets VDL should 
process .view.xml files if this mapping isn't reflected by the default 
values of these context parameters?

> SUBSECTION: derived view id changes
>
> LU> It seems, but note the algorithm required to deriveViewId() should
> LU> call ResourceResolver to check for resources, specially when suffix
> LU> mapping is used, so if it is necessary to change section 7.5.2 for
> LU> each problem, it could be good to do both changes at once.
>
> What changes are necessary to 7.5.2?
>   

7.5.2 does not specify exactly how the deriveViewId() implementation 
should check for the existence of a physical view.  The wording is generic:

> look for a physical resource with the name candidateViewId. If such a 
> resource exists, candidateViewId is the correct viewId

As of 2.1, we have introduced a new method that performs this test: 
ViewDeclarationLanguage.viewExists().  7.5.2 could add a sentence that 
states that this method should be used to perform the view existence test.

> AS> 4. We need some way to wrap a specific VDL (eg. the JSP VDL).  The
> AS> minimal solution would be to introduce a VDL id (eg.
> AS> ViewDeclarationLanguage.getId()) and define standard ids for the JSP
> AS> and Facelets VDLs.
>
> I'm not opposed, but can you clearly articulate, in one or two
> sentences, why we need this?
>   

I need the ability to wrap one of the standard VDL implementations (the 
JSP VDL implementation) in order to insert my own logic.  (In my case, I 
need to substitute my own VDL.viewExists() implementation).  While the 
VDLFactory contract provides a hook for this, I have no way to 
distinguish between VDL implementations.  The presence of an id lets me 
to know which VDL is being returned from the VDLFactory and thus allows 
me to target my wrapper to a single VDL.

> SUBSECTION: XML syntax
>
> CH> A user could actually nominate http://java.sun.com/jsf/html as the
> CH> namespace without a prefix and prefix the html tags--don't know if
> CH> that's attractive to anyone.
>
> Yes, they could, but I've not seen any books or articles that do it that
> way. I assert that you can't have a proper XML Faces view without having
> exactly one of the following
>
> 1. some kind of root element on which namespaces are declared
>   

We've got a few options here:

- <html>
- <h:html>
- <f:view>

> 2. doing what Cay suggests and just have "html" as the root element, but
> have it be the new html renderer that handles the "html" element
> rendering.
>   
> 3. saying that your view is actually an XHTML view, in which case you
> have <html> as the root element with the XHTML namespace as the
> non-prefixed namespace.
>   

I *think* that it should be okay to just use a plain old <html> element 
even when processing mode = xml.  Is there a reason why we should 
disallow this?

A big concern about our current XML-centric solution: at the moment we 
don't seem to have any clean way to specify a doctype.  And since 
<h:html> doesn't render a doctype, it looks like our XML-style Facelets 
pages will be doctype-less.  This seems like a very serious 
shortcoming.  I think that we need to address this.

> SECTION: [UIData transient] [6] [7]
>   

> MM> - get/putTransient should be on UIComponent, or TransientStateHelper
> MM> needs to be exposed
>
> I strongly feel we shoul expose TransientStateHelper, not put these
> methods on UIComponent.
>
> MM> - no Serializable keys are necessary
>
> MM> But - I am not sure about removing the TransientStateHelper
> MM> contract... It doesn't need to extend from StateHelper, that is true
> MM> - but won't the code look funny if state-saved property handling
> MM> looks different from transient property handling?
>
> Andy's definitive patch is at [7].  Both Andy and Blake favor this patch
> because it does not introduce a top-level TransientStateHelper
> interface.
>
> MM> What I would do:
>
> MM> Double getCalculatedWeight() {
> MM>   return (Double) getTransientStateHelper().get(PropertyKeys.weight, false);
> MM> }
> MM> void setCalculatedWeight(Double weight) {
> MM>   getTransientStateHelper().put(PropertyKeys.weight, weight);
> MM> }
> MM> 
> MM> Could TransientStateHelper not be an alternative implementation of the
> MM> StateHelper interface?
>
> This is completely analogous to the original design with StateHelper().
> So, in addition to Martin's assertion about the API design, it is
> consistent with our existing patterns.
>
> I'm not convinced {get/put}Transient is better.  If you're going to
> quibble with that, why not quibble with getStateHelper() as well?
>   

StateHelper is a helper class that is helps the component implementation 
and its subclasses.  The access modifier of getStateHelper() reflects 
this - ie. this is a protected, not public.

With transient state, I was under the impression that we were trying to 
address two use cases:

- Internal access from the component + subclasses.
- External access from arbitrary code (eg. Renderers, application logic)

The second use case raises the question of what an appropriate 
external/public API might be.  I find it awkward that external code 
would be required to interact with a UIComponent's "helper" class.

I don't view this as quibbling.  We're all just trying to find the best API.

> AS> I don't see how adding a new TransientStateHelper contract improves
> AS> this situation.  That's not to say that we cannot do this.  The
> AS> first patch that I provided leaves TransientStateHelper in place.
> AS> Just seems like added conceptual overhead that might not be
> AS> necessary.
>
> AS> 1.  Components storing transient attributes on themselves.
> AS> 2.  External classes storing transient attributes on components.
>
> The existing StateHelper only addresses 1.  Is it ok to allow transient
> state to be accessed for case 2 without doing the same for non-transient
> state?
>   

Non-transient state is already accessible via public APIs on UIComponent 
(eg. getAttributes(), getValueExpression(), etc...) and its subclasses 
(eg. property-specific getters/setters).   The fact that UIComponent 
happens to store state in a StateHelper is effectively an implementation 
detail of the component.

BTW, I haven't seen any comments on the questions that I raised 
regarding TransientStateHolder.  Who implements this besides 
UIComponent?  Who interacts with this contract?

> SECTION: [537-PrePostValidateEvent]
>
> AS> Does this mean that only input, UIData and UIForm components will
> AS> deliver these events?
>
> No, it does not mean that *only* those components will deliver those
> events.  It means that in the case of components who are iterating
> components, the event must be published before, or after, the child
> component processing.  This is true for any components that have
> children.  I will revise the documentation to be as follows.
>
> PostValidateEvent
>
> Components with children must publish this event after processing their
> child nodes in processValidators.  This is especially important for
> iterating components such as UIData and form components, such as UIForm.
>
>   

Okay, though I am still a bit confused about how iterating components 
are special.

As always, I also worry that the overhead of delivering these system 
events through the application-level publication mechanism is going to 
be a performance problem for views with large #s of components (common 
case for me).  I suppose time will tell.

Andy