What goes in a JSF ActionEvent vs. a Managed Bean do method?

[Cameron Wallace McKenzie]

So, when someone clicks a button in a Java ServerFaces application, it typically hits a managed bean's "doXYZ" method. The returned String then works with faces-config.xml navigation elements to figure out which pages to display.

Before a JavaServer Faces managed bean's do method is hit, a button can also trigger an ActionEvent. The action event can actually be a method in the managed bean, it can work on validated and converted values in the managed bean, and of course, it can interact with other JEE components such as database, EJBs, message queues, etc.

So, if I have logic that runs when a button is clicked, should I code it in a 'do' method of a managed bean, or should I code it in an ActionListener? When should processing go in a managed bean's 'do method' and when should processing go in a Java Server Faces ActionListener?

In the past, it seems most projects I've on just put everything in the 'do method', but the more I read about JSF, the more I think only page navigation stuff should go in the doXYZ method, and significant logic should go in an ActionListener.

Any suggestions or pearls of wisdom on how to best design and architect a JavaServerFaces application?

-Cameron McKenzie

[Cameron Wallace McKenzie]

"If no navigation is needed after an action event, one can write an action listener method. In contrast to an action method, an action listener method simply executes and no navigation is expected as a result. As a result, the action listener method returns void."

JSF Complete Reference, Ed Burns

So, that's the 'reference' explaination. But like everything else JSF, it describes the API, but doesn't give any guidance on how to use it. If there is no navigation, the use an ActionEvent. But what if you decide later you want navigation? Do you then move the code to a managed bean 'doAction' method? Or, do you delinate, and design so you have modular processes in ActionEvent objects, and leave simple navigation choices to the doAction method? Surely, having an ActionObject, and later thinking you need navigation, you wouldn't just discard the ActionObject and recode everything into a new 'doAction' method in a managed bean, would you?

Anybody can code. It's designing things properly that is the skill. So, how do you properly design JSF apps?

-Cameron McKenzie

[Kavita Tipnis]

A doAction method in JSF knows nothing about which jsf component was clicked(or fired the event) , it will just take part in the navigation.
However, if you want details about the component that fired the event , then action listener is your only choice.
From a design perspective , you can have both to keep things clean. (This is my naive opinion!)

I have used both in a following scenario :
A datatable shows a list of items in the cart. on clicking every item, you are navigated to a results page which shows details specific to each item.
So here, the results page is the same for all items in the table, but for each row/each item , on clicking , the ActionEvent fetches relevant information
For effective design IMO , actionListeners can take care of business logic and simple action methods can take care of UI or navigation.


Hope I am not off track!

[Cameron Wallace McKenzie]

if you want details about the component that fired the event , then action listener is your only choice.

That's an interesting point. So, can we say we should only code logic in an actionListener if information about the object firing the event is important, otherwise, the logic should be in a 'doAction' method of a JSF managed bean? Probably not, but it's an interesting idea.

For effective design IMO , actionListeners can take care of business logic and simple action methods can take care of UI or navigation.

I like this idea, although it does ignore the pertinence of information about the 'firing object' in the action Listener. I've seen most places put everything into the managed bean doAction, as though it was the equivalent of a Struts action class. But what you mention just seems more in line with how it seems JSF was developed. If you can write the code in both places, there must be a compelling reason these two components exist. Indeed, putting important code in an actionListener, and leaving navigation heavy decisions in the doAction method of a managed bean seems like a nice way to delineate workload.

I have found it rather disappointing that the big books on JSF, not to mention the spec, tend to deal with what individual components can do, while lacking any good leadership with regards to how to design a Java ServerFaces application. And it's poor design that usually dooms Java development projects to failure.

Thanks for indulging me in this philisophical design debate. I'd love to hear other people's ideas on the subject!

-Cameron McKenzie

[Kavita Tipnis]

Cameron Wallace McKenzie wrote: If you can write the code in both places, there must be a compelling reason these two components exist.

There is a reason, Core JSF by Geary and Horstmann(2nd Edition) tries to explain this.
Traditionally, action listeners are known to handle all the business logic, however with JSF,page navigation got rephrased as view navigation,
so a view handler was needed which could make the decisions to select the next view after an action occurred. I believe to provide this functionality and action attribute was added to the UICommand components in JSF.

I have found it rather disappointing that the big books on JSF, not to mention the spec, tend to deal with what individual components can do, while lacking any good leadership with regards to how to design a Java ServerFaces application. And it's poor design that usually dooms Java development projects to failure.

I agree, I have been an entry level developer fresh out of college for just more than a year, and at my current Job, I am the lone programmer for web applications.I am learning the benefits of good design as I am delivering new web apps.
I am fairly happy that I could model my JSF apps in accordance with the J2EE patterns.
But instead of spending millions on debugging and fixing, it would be rather cost effective if project model and design is given more thought.
By model and design, I do not just mean the UML diagrams and case studies
but given a functional requirement, how would it translate to your current framework.

There are several experienced ranchers on this JSF forum who would have more insight
on this than me!

Thanks for indulging me in this philisophical design debate. I'd love to hear other people's ideas on the subject!

It is rewarding to have a conversation with an author!