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

Tue Oct 26 17:40:23 EDT 2010

On the SystemEvent issue, we already know that its design causes 
performance problems even when there are no listeners.

-- Blake Sullivan

On 10/26/10 2:26 PM, Andy Schwartz wrote:
> 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
>