This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
But i don't understand the need of the second one, infact in both I can write what i want inside the method.
I mean, what is customizable in the second one that is not possible in the first one?
JSF was really confusing while it was being designed originally, and I think that action methods might not have existed then, because an awful lot of people use listeners when they shouldn't and the only reasons I can come up with is because they either were using out-of-date documentation or they wanted a complicated solution to a simple problem.
ActionListeners are something I almost never use, because they require JSF-aware code and usually don't do anything that a POJO action method cannot do without the need to tie the code to JSF or to the JSF runtime (which means it's a lot easier to run offline testing).
However, there are exceptions. A downside of action methods is that for a given command control, there can be only one action method. However, you can jam as many action listeners on that control as you want to. They will, of course, all need to be JSF-aware, but in some cases that's simpler than the alternative, which would be to aim the control at a master action method whose job was to invoke multiple secondary action methods.
Customer surveys are for companies who didn't pay proper attention to begin with.