File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes Good Design of JSF Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Good Design of JSF" Watch "Good Design of JSF" New topic
Author

Good Design of JSF

liliane fahmy
Greenhorn

Joined: Aug 24, 2012
Posts: 22
Hi all,
would you please give me an advice to make a good design of JSF.
I used to put the action and event methods in the backing bean (I know the different types of managed beans) ,
but someone tell me that the backing bean must contain getter and setter only ,not else.

So what is your advice ?

Thanks for advance reply
Waqar Azam
Greenhorn

Joined: Feb 27, 2013
Posts: 6
Hello!
I am also new to JSF and i am studying it thoroughly .. so far as i have studied it the best practice is keep your been class simple and put getter and setter methods only in the bean class... and rest of your logic in other class or classes...From what I can make out, a JavaBean is basically a class just like any other java class except that it adheres to certain conventions, i.e.:

The class must implement Serializeable
Class properties are assumed to be private and their names start with a lowercase letter
Each property must have it's respective getter and setter methods.
Each setter method starts with the prefix 'get' followed by the property name e.g. setName()
Setter methods are public and void
Same applies to the getter methods (prefix 'get', public, return type respective property class type etc.)
For boolean properties instead of 'get' one uses the prefix 'is'
Strictly speaking it is the instance of the class that is considered a 'bean' not the class itself.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15950
    
  19

Waqar Azam wrote:Hello!
I am also new to JSF and i am studying it thoroughly .. so far as i have studied it the best practice is keep your been class simple and put getter and setter methods only in the bean class... and rest of your logic in other class or classes...From what I can make out, a JavaBean is basically a class just like any other java class except that it adheres to certain conventions, i.e.:

The class must implement Serializeable
Class properties are assumed to be private and their names start with a lowercase letter
Each property must have it's respective getter and setter methods.
Each setter method starts with the prefix 'get' followed by the property name e.g. setName()
Setter methods are public and void
Same applies to the getter methods (prefix 'get', public, return type respective property class type etc.)
For boolean properties instead of 'get' one uses the prefix 'is'
Strictly speaking it is the instance of the class that is considered a 'bean' not the class itself.


I don't know about you guys. Trying to understand JSF instead of just blindly charging in and trying to make it work by brute force? What's this world coming to?

Rule #1 for JSF: The more "JSF-like" your code is, the more likely you are doing it wrong. Any time I see a reference to a javax.faces item and it's not one of the JSF Model classes or interfaces, alarms go off in my head.

JSF is designed to allow as much code as possible to be POJO. Plain Old Java Objects (also known as JavaBeans). All of the above rules are JavaBean rules, and not limited to JSF. Any POJO-based system (such as Spring Framework) also carry those constraints. It is not true, however, that POJOs must be Serializable. That's only required if the object has external requirements. For example JSF session-scope objects are J2EE session-scope objects, and J2EE is what requires them to be serializable. request-scope objects don't require serializability (although in JSF request scope is mostly useless).

In JSF, the backing beans may be property holders, code holders, or both. The code is things like action methods, which are no-argument public methods returning a String (for navigation) or void (in JSF2, if no navigation is required). They may also contain other things, such as Listeners, but remember Rule #1 and don't over-indulge. AJAX listeners are somewhat of an exception, but even they can be coded POJO-style in many cases.

Most of the JSF functionality is applied from the outside, not from the inside. This concept is formally known as Inversion of Control (IoC). IoC makes it possible to keep components independent of each other, which makes them more re-usable and easier to test.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Good Design of JSF
 
Similar Threads
Backing Bean in JSF 1.2
Backingbean in session scope not working
JSF Portlet and instance variables
Backing Beans and CDI Beans
Very basic problem-where should the action method will be in?