Differences between action and actionListener

Question

What is the difference between action and actionListener  and when should I use action versus actionListener

User · Answer

ActionListener gets fired first  with an option to modify the response  before Action gets called and determines the location of the next page   If you have multiple buttons on the same page which should go to the same place but do slightly different things  you can use the same Action for each button  but use a different ActionListener to handle slightly different functionality   Here is a link that describes the relationship   http   www java-samples com showtutorial php tutorialid 605

User · Answer

TL DR   The ActionListeners  there can be multiple  execute in the order they were registered BEFORE the action   Long Answer   A business action typically invokes an EJB service and if necessary also sets the final result and or navigates to a different view if that is not what you are doing an actionListener is more appropriate i e  for when the user interacts with the components  such as h commandButton or h link they can be handled by passing the name of the managed bean method in actionListener attribute of a UI Component or to implement an ActionListener interface and pass the implementation class name to actionListener attribute of a UI Component

User · Answer

As BalusC indicated  the actionListener by default swallows exceptions  but in JSF 2 0 there is a little more to this  Namely  it doesn t just swallows and logs  but actually publishes the exception   This happens through a call like this   context getApplication   publishEvent context  ExceptionQueuedEvent class                                                                new ExceptionQueuedEventContext context  exception  source  phaseId       The default listener for this event is the ExceptionHandler which for Mojarra is set to com sun faces context ExceptionHandlerImpl  This implementation will basically rethrow any exception  except when it concerns an AbortProcessingException  which is logged  ActionListeners wrap the exception that is thrown by the client code in such an AbortProcessingException which explains why these are always logged   This ExceptionHandler can be replaced however in faces-config xml with a custom implementation    lt exception-handlerfactory gt     com foo myExceptionHandler  lt  exception-handlerfactory gt    Instead of listening globally  a single bean can also listen to these events  The following is a proof of concept of this    ManagedBean  RequestScoped public class MyBean        public void actionMethod ActionEvent event             FacesContext getCurrentInstance   getApplication   subscribeToEvent ExceptionQueuedEvent class  new SystemEventListener               Override         public void processEvent SystemEvent event  throws AbortProcessingException               ExceptionQueuedEventContext content    ExceptionQueuedEventContext event getSource                throw new RuntimeException content getException                         Override         public boolean isListenerForSource Object source                return true                                 throw new RuntimeException  test                note  this is not how one should normally code listeners  this is only for demonstration purposes    Calling this from a Facelet like this    lt html xmlns  http   www w3 org 1999 xhtml      xmlns h  http   java sun com jsf html      xmlns f  http   java sun com jsf core  gt       lt h body gt           lt h form gt               lt h commandButton value  test  actionListener    myBean actionMethod    gt           lt  h form gt       lt  h body gt   lt  html gt    Will result in an error page being displayed

User · Answer

actionListener Use actionListener if you want have a hook before the real business action get executed  e g  to log it  and or to set an additional property  by  lt f setPropertyActionListener gt    and or to have access to the component which invoked the action  which is available by ActionEvent argument   So  purely for preparing purposes before the real business action gets invoked  The actionListener method has by default the following signature  import javax faces event ActionEvent          public void actionListener ActionEvent event                  And it s supposed to be declared as follows  without any method parentheses   lt h commandXxx     actionListener  quot   bean actionListener  quot    gt   Note that you can t pass additional arguments by EL 2 2  You can however override the ActionEvent argument altogether by passing and specifying custom argument s   The following examples are valid   lt h commandXxx     actionListener  quot   bean methodWithoutArguments    quot    gt   lt h commandXxx     actionListener  quot   bean methodWithOneArgument arg1   quot    gt   lt h commandXxx     actionListener  quot   bean methodWithTwoArguments arg1  arg2   quot    gt    public void methodWithoutArguments      public void methodWithOneArgument Object arg1     public void methodWithTwoArguments Object arg1  Object arg2      Note the importance of the parentheses in the argumentless method expression  If they were absent  JSF would still expect a method with ActionEvent argument  If you re on EL 2 2   then you can declare multiple action listener methods via  lt f actionListener binding gt    lt h commandXxx     actionListener  quot   bean actionListener1  quot  gt       lt f actionListener binding  quot   bean actionListener2    quot    gt       lt f actionListener binding  quot   bean actionListener3    quot    gt   lt  h commandXxx gt    public void actionListener1 ActionEvent event     public void actionListener2      public void actionListener3       Note the importance of the parentheses in the binding attribute  If they were absent  EL would confusingly throw a javax el PropertyNotFoundException  Property  actionListener1  not found on type com example Bean  because the binding attribute is by default interpreted as a value expression  not as a method expression  Adding EL 2 2  style parentheses transparently turns a value expression into a method expression  See also a o  Why am I able to bind  lt f actionListener gt  to an arbitrary method if it  39 s not supported by JSF   action Use action if you want to execute a business action and if necessary handle navigation  The action method can  thus  not must  return a String which will be used as navigation case outcome  the target view   A return value of null or void will let it return to the same page and keep the current view scope alive  A return value of an empty string or the same view ID will also return to the same page  but recreate the view scope and thus destroy any currently active view scoped beans and  if applicable  recreate them  The action method can be any valid MethodExpression  also the ones which uses EL 2 2 arguments such as below   lt h commandXxx value  quot submit quot  action  quot   bean edit item   quot    gt   With this method  public void edit Item item                  Note that when your action method solely returns a string  then you can also just specify exactly that string in the action attribute  Thus  this is totally clumsy   lt h commandLink value  quot Go to next page quot  action  quot   bean goToNextpage  quot    gt   With this senseless method returning a hardcoded string  public String goToNextpage         return  quot nextpage quot      Instead  just put that hardcoded string directly in the attribute   lt h commandLink value  quot Go to next page quot  action  quot nextpage quot    gt   Please note that this in turn indicates a bad design  navigating by POST  This is not user nor SEO friendly  This all is explained in When should I use h outputLink instead of h commandLink  and is supposed to be solved as  lt h link value  quot Go to next page quot  outcome  quot nextpage quot    gt   See also How to navigate in JSF  How to make URL reflect current page  and not previous one    f ajax listener Since JSF 2 x there s a third way  the  lt f ajax listener gt    lt h commandXxx     gt       lt f ajax listener  quot   bean ajaxListener  quot    gt   lt  h commandXxx gt   The ajaxListener method has by default the following signature  import javax faces event AjaxBehaviorEvent          public void ajaxListener AjaxBehaviorEvent event                  In Mojarra  the AjaxBehaviorEvent argument is optional  below works as good  public void ajaxListener                   But in MyFaces  it would throw a MethodNotFoundException  Below works in both JSF implementations when you want to omit the argument   lt h commandXxx     gt       lt f ajax execute  quot  form quot  listener  quot   bean ajaxListener    quot  render  quot  form quot    gt   lt  h commandXxx gt   Ajax listeners are not really useful on command components  They are more useful on input and select components  lt h inputXxx gt   lt h selectXxx gt   In command components  just stick to action and or actionListener for clarity and better self-documenting code  Moreover  like actionListener  the f ajax listener does not support returning a navigation outcome   lt h commandXxx     action  quot   bean action  quot  gt       lt f ajax execute  quot  form quot  render  quot  form quot    gt   lt  h commandXxx gt   For explanation on execute and render attributes  head to Understanding PrimeFaces process update and JSF f ajax execute render attributes   Invocation order The actionListeners are always invoked before the action in the same order as they are been declared in the view and attached to the component  The f ajax listener is always invoked before any action listener  So  the following example   lt h commandButton value  quot submit quot  actionListener  quot   bean actionListener  quot  action  quot   bean action  quot  gt       lt f actionListener type  quot com example ActionListenerType quot    gt       lt f actionListener binding  quot   bean actionListenerBinding    quot    gt       lt f setPropertyActionListener target  quot   bean property  quot  value  quot some quot    gt       lt f ajax listener  quot   bean ajaxListener  quot    gt   lt  h commandButton gt   Will invoke the methods in the following order   Bean ajaxListener   Bean actionListener   ActionListenerType processAction   Bean actionListenerBinding   Bean setProperty   Bean action     Exception handling The actionListener supports a special exception  AbortProcessingException  If this exception is thrown from an actionListener method  then JSF will skip any remaining action listeners and the action method and proceed to render response directly  You won t see an error exception page  JSF will however log it  This will also implicitly be done whenever any other exception is being thrown from an actionListener  So  if you intend to block the page by an error page as result of a business exception  then you should definitely be performing the job in the action method  If the sole reason to use an actionListener is to have a void method returning to the same page  then that s a bad one  The action methods can perfectly also return void  on the contrary to what some IDEs let you believe via EL validation  Note that the PrimeFaces showcase examples are littered with this kind of actionListeners over all place  This is indeed wrong  Don t use this as an excuse to also do that yourself  In ajax requests  however  a special exception handler is needed  This is regardless of whether you use listener attribute of  lt f ajax gt  or not  For explanation and an example  head to Exception handling in JSF ajax requests

[jsf] Differences between action and actionListener

Examples related to jsf

Examples related to jsf-2

Examples related to action

Examples related to actionlistener