Action method called before the listener

Question

hi all;
i have a command_link as follows:
<h:command_link action="#{someBean.someMethod}" >
     <f:parameter name="param" value="0"/>
     <h:output_text value="#{someBean.someProperty}"/>
     <f:action_listener type="com.myListener" />
</h:command_link>
my problem is that the listener is called AFTER the bean method is called. i need my bean to use data that is set by the listener so i need the listener to be called BEFORE that method.
on EA4 i used the getPhaseID but now its gone and i cant seem to find the proper replacement.
i tried the immediate="true" attribute on the command_link with no success, the results were the same.
any help is appreciated.

Answer 1

I believe that what's really going on here is that
"action" should always be processed after all action
listeners, when, in fact, it's always processed first.
I'll raise this on the EG.
AIUI it's even more confusing than your description implies. There seem to be three things
that can be triggered from a <command_button> or <command_link>:
1. ActionListeners registered using a nested <action_listener> tag.
2. An action listener method declared using the actionlistener attribute.
3. An action method declared using the action attribute.
I don't think the spec defines a relative ordering for all of these possible event handlers, but I
think it works like this:
A. All the action listeners are called in an undefined order. This takes care of all those in
category (1) above. Since one of the listeners is the system-defined default listener,
at some point during this processing, the action method (which is REALLY the application code)
is also called. However, since the spec is vague, you don't really know where this happens relative to
the other listeners.
B. The method referred by the actionlistener attribute in category 2 above is called.
I would have thought that the most intuitive order would be:
1. All of the action listeners, whether added using <action_listener> or declared using the
actionlistener attribute.
2. The method referred to by the action attribute (i.e. the real application code).
I think the current implementation, where (2) is done by a system-defined actionlistener, gets in the
way of achieving this, and that would have to change in order to produce a well-defined result.