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

[Andy Schwartz]

Thanks Pete.

Quick follow up question...

For <f:ajax>, if the component contains a locally specified behavior we
currently do not apply the ancestor <f:ajax> behavior.  So, for example,
in this case:

<f:ajax>
    <h:commandButton>
        <!-- Inner behavior wins -->
        <f:ajax disabled="true"/>
    </h:commandButton>
</f:ajax>

The inner <f:ajax> wins - and we do not apply the outer/wrapping
<f:ajax> to the commandButton.

This is true if any Behavior is present, not just <f:ajax>.  So assuming
<foo:showAlert> is a custom Behavior implementation:

<f:ajax>
    <h:commandButton>
        <foo:showAlert>
    </h:commandButton>
</f:ajax>

In this case, even though there is no local <f:ajax>, the presence of
the <foo:showAlert> is sufficient to prevent the outer <f:ajax> from
being applied.  The idea is that we assume that if the page author is
attaching Behaviors to the component, they have explicitly specified the
behaviors that they want, so we don't bother mucking with the behaviors
that they have specified.

An alternative would be to apply the wrapping <f:ajax> as long as there
is no nested <f:ajax> (or actually, no nested "submitting" behavior).  I
wasn't sure want the best behavior would be, so if anyone has opinions,
please let me know.

How does <f:validateBean> deal with this case?  For example:

<f:validateBean>
    <h:inputText>
        <f:validateLength/>
    </h:inputText>
</f:validateBean>

Is a bean validator added to the inputText in addition to the length
validator?

Andy

Pete Muir wrote On 3/10/2009 6:14 PM ET:
> Hey,
>
> Aha, I forgot about that ordering discussion. Hrm. If the ordering
> thing is an issue with f:validateBean, then we should go with a nested
> approach I guess (though it is a little more verbose)... Dan?
>
> This is also the tried and tested solution (aka s:validateAll in Seam).
>
> On 10 Mar 2009, at 18:50, Andy Schwartz wrote:
>
>> Hi Pete -
>>
>> Pete Muir wrote On 3/10/2009 2:15 PM ET:
>>> Actually, this isn't right. It would look like
>>>
>>> <h:panelGroup>
>>> <!-- Turn on bean validation for the two input texts -->
>>>     <f:validateBean validationGroups="Group1, Group2"/>
>>>     <h:inputText value="foo"/>
>>>     <h:inputText value="bar"/>
>>> </h:panelGroup>
>>>
>>> Which would enable validation for the whole panel group.
>>>
>>> Having looked back at the previous messages, I think we went for the
>>> nested element enables validation for the panel group on your advice
>>> that this would unify us with f:ajax...
>>>
>>> But this seems to be missing from the final Ajax design?
>>
>> The EG rejected the "nested <f:ajax> enables Ajax for the entire
>> subtree rooted at the parent" approach as several people found it
>> confusing.  See the discussion in the "AjaxBehavior inheritance
>> strategy" thread which starts on 14 Nov.  For those who have access
>> to the old EG archives, the thread starts here:
>>
>> http://tinyurl.com/dndt5v
>>
>> We ended up going with the solution that you recommended here:
>>
>> http://tinyurl.com/bjo97c
>>
>> Looking back at this thread, it seems like there was general
>> agreement to go with the "wrapping" approach, but apologies if we
>> failed to make our change in direction clear.
>
> No, it's just my memory being a bit creaky...
>
> --
> Pete Muir
> http://www.seamframework.org
> http://in.relation.to/Bloggers/Pete