[jsr-314-open] [NEW] <f:ajax> and <f:validateBean> - consistent wrapping solution needed?

[Roger Kitain]

+1  - But I'm biased too...   ;-)

Andy Schwartz wrote:
> Gang -
>
> In JSF 2.0 we are introducing two core tags that wrap/enhance
> component subtrees: f:ajax and f:validateBean.
>
> f:ajax is used to enable Ajax behavior for a subtree, eg:
>
>> <h:panelGroup>
>>   <!-- Turn on Ajax for the two input texts -->
>>   <f:ajax event="valueChange">
>>       <h:inputText value="foo"/>
>>       <h:inputText value="bar"/>
>>   </f:ajax>
>> </h:panelGroup>
>
>
> f:validateBean is used to enable bean validation for a subtree, eg:
>
>> <h:panelGroup>
>>   <!-- Turn on bean validation for the two input texts -->
>>   <f:validateBean validationGroups="Group1, Group2"/>
>>       <h:inputText value="foo"/>
>>       <h:inputText value="bar"/>
>>   </f:validateBean>
>> </h:panelGroup>
>
> Of course, both tags can also be used in their nested form to enable
> Ajax/bean validation on a single component.
>
> We currently use different implementation strategies for the
> "wrapping" behavior.
>
> f:ajax uses a handler execution-time solution.  AjaxHandler maintains
> a stack that keeps track of the current nested state of <f:ajax>
> tags.  Before apply child handlers, AjaxHandler pushes the current
> Ajax-related info onto this stack.  When child/descendent handlers are
> applied, ComponentTagHandlerDelegateImpl checks this stack to get at
> the current Ajax-related state and performs the necessary work to wire
> up an AjaxBehavior to the component.  Finally, after child handlers
> have been processed, AjaxHandler pops the stack, and we're done.
>
> The end result of the f:ajax solution is that once handlers have
> finished executing, we have a fully configured component tree.  No
> further processing is necessary to apply "inherited" Ajax behavior.
>
> f:validateBean uses a solution which is split between tag/handler
> execution-time, validation-time and render-time.
> BeanValidatorHandler/ValidatorTagHandlerDelegateImpl set up well known
> properties on the parent component's attribute map (eg.
> BeanValidator.VALIDATION_GROUPS_KEY,
> UIInput.DEFAULT_VALIDATOR_IDS_KEY).  These are used during later
> lifecycle phases (eg. BeanValidator.validate(), UIInput.encodeEnd())
> to determine which inherited validators to apply and how these
> validators should be configured (eg. what validation groups to use).
>
> The end result of the f:validateBean solution is that the handlers
> only do part of the job - we need to do additional work during later
> lifecycle phases to take advantage of the information that has been
> stored away by the handlers.
>
> While these two different strategies may at first seem like
> implementation details, and thus not especially significant, the
> choice of implementation does have impact on both our API and on
> spec'ed behavior (or, on behavior that should be defined by the spec).
>
> In terms of API, for f:validateBean the choice of implementation leaks
> through a bit into the API in the form of the property keys that are
> used to communicate between the handler implementations and the
> component/validator implementations.
>
> In terms of behavior, the different implementation strategies and up
> with subtly different results which may cause confusion.
>
> For example, in the following f:ajax case:
>
>> <h:panelGroup>
>>
>>   <!-- Turn Ajax on for this one -->
>>   <f:ajax event="valueChange">
>>       <h:inputText value="foo"/>
>>   </f:ajax>
>>
>>   <!-- But not for this one -->
>>   <h:inputText value="bar"/>
>>
>> </h:panelGroup>
>
>
> This should work as expected.  That is, Ajax should be enabled for the
> "foo" inputText, but not for the "bar" input text.
>
> In a similar f:validateBean case:
>
>> <h:panelGroup>
>>
>>   <!-- Turn bean validation on for this one -->
>>   <f:validateBean validationGroups="Group1, Group2"/>
>>       <h:inputText value="foor"/>
>>   </f:validateBean>
>>
>>   <!-- But not for this one -->
>>   <h:inputText value="bar"/>
>>
>> </h:panelGroup>
>
>
> Unless I am missing something in the spec/implementation, I believe
> that the validation-related properties are going to end up being
> attached to the parent panelGroup when the BeanValidatorHandler is
> applied.  Which, if I understand this correctly, means that the
> validation will be applied to both the "foo" and the "bar" inputText.
> If this is the case, this is definitely not the desired behavior.
>
> I suspect that similar problems would arise when we've got multiple
> <f:validateBean> under a single parent, eg:
>
>> <h:panelGroup>
>>
>>   <!-- Turn on Group1 validation for this one -->
>>   <f:validateBean validationGroups="Group1"/>
>>       <h:inputText value="foo"/>
>>   </f:validateBean>
>>
>>   <!-- Turn on Group2 validation for this one -->
>>   <f:validateBean validationGroups="Group2"/>
>>       <h:inputText value="bar"/>
>>   <f:validateBean/>
>>
>> </h:panelGroup>
>
>
> Though I haven't had a chance to test this out - just based on code
> inspection seems like this would be a problem.  (Though our <f:ajax>
> implementation strategy handles this case just fine.)
>
> Since there may be other subtle inconsistencies, it would make sense
> to try to unify our implementation strategies across these two core
> tags.  Of course, I am biased towards the <f:ajax> approach.  Seems to
> have better behavior in terms of targeting only the wrapped subtrees,
> has less exposure in the public API, and also just seems cleaner to me
> to produce a fully configured component tree as a result of handler
> execution.
>
> Looking at the code, I didn't notice anything that would make it
> difficult to re-factor the <f:validateBean> code  to use a
> handler-time strategy like <f:ajax>.  I think our users would benefit
> from the consistency.  Any thoughts on whether we should/can go this
> route?  Did I miss anything in the <f:validteBean> behavior that would
> prevent us from using a handler-time solution?
>
> Andy