That's what I figured and that's fine. Just for fun let me present my
full use case and what I expected would happen. So, pretend you have
a set of form elements. You want to validate the form elements
differently depending upon what button is pressed.
<h:form>
<h:inputText validator="#{test.validate}"
value="#{test.stringValue}"/>
<h:commandButton actionListener="#{test.numeric}"
value="Numeric" immediate="true"/>
<h:commandButton actionListener="#{test.alphaNumeric}"
value="AlphaNumeric" immediate="true"/>
<h:commandButton value="Cancel" action="cancel"
immediate="true"/>
</h:form>
If "Numeric" is pressed then test.numeric would set a value in the
managed bean that test.validate would use to determine how it should
validate the button. Because no action is specified no navigation
would take place and all phases of the lifecycle would be hit. Same
thing for alphaNumeric.
If Cancel is pressed then no validation would occur. The page would
navigate to the cancel rule and the phases would be short circuited.
So, from an implementation perspective this is how I thought such a
situation would be implemented.
1. The default action listener would not call renderResponse(). The
Navigation handler would still be called just the response would not
immediatly be rendered. (This is assuming that if renderResponse is
not called that after invoke application the response would
automatically be rendered anyway weather renderResponse() was called
or not.)
2. All Action events would then function exactly the same as
valueChangeEvents. If the event wanted to immediately call
renderResponse() then that would be the responsibility of the event
handler writer just like valueChangeEvents.
3. If a String is specified in the "action" attribute then UICommand
would create it's default action handler just like it does not but the
default action handler that wraps the string would call
renderResponse().
Does anyone think such an implementation approach would make any more
or less sense than the way it is implemented now? The only change
would be to remove renderResponse() from the default
ActionListenerImpl and add renderResponse to the UICommand's default
action handler. I'm not super versed in the spec but I don't see
anyplace right off hand that says ActionListenerImpl must call
renderResponse().
Any thoughts?
Mike
On 4/13/06, Roger Kitain <Roger.Kitain_at_sun.com> wrote:
> As you've discovered, the immediate attribute can be tricky if not used
> properly.
> In your small example, it is unlikely that you would want your default
> actionListener
> to be called before validation anyway.. However, if you add
> "immediate=true" to
> inputText component as well, then you should get the ValueChangeListener
> execution as well.
>
> -roger
>
> Michael Youngstrom wrote:
>
> >I feel I have a pretty good grasp on things in JSF and then suddenly
> >some functionality throws me for a loop.
> >
> >The latest loop I've been thrown is that apparently when immediate is
> >set on a UICommand component then after ApplyRequestValues all other
> >phases are automatically short circuited.
> >
> >Given the following example:
> >
> > <h:form>
> > <h:inputText valueChangeListener="#{test.validate}"
> >value="#{test.stringValue}"/>
> > <h:commandButton value="Immediate" immediate="true"/>
> > </h:form>
> >
> >If I input some values into the inputText then click the button
> >"Immediate" #{test.validate} is never called. This happens because
> >com.sun.faces.application.ActionListenerImpl is being called which
> >calls context.renderResponse().
> >
> >For some reason I always thought that an immediate ActionEvent would
> >only short circuit the rest of the phases if a user specific
> >actionListener associated with the component called renderResponse().
> >Am I wrong or is this a bug?
> >
> >Granted I cannot think of many cases where an immediate button press
> >would not want to render the response right away it just caught me off
> >guard.
> >
> >Mike
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> >For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
>
>