webtier@glassfish.java.net

Re: JSF application Design Clarification

From: Ed Burns <Ed.Burns_at_Sun.COM>
Date: Tue, 09 Sep 2008 11:36:16 -0400

>>>>> On Wed, 03 Sep 2008 22:42:39 -0400, Lalith P Vaka <Lalith_P_Vaka_at_healthnow.org> said:

LV> Hello Ed,

LV> Have a quick question. Recently I have implemented JSF for one of my
LV> projects and I have a design issue that I am not real sure about. I have
LV> used two seperate classes out of which one has typical Bean methods (Getter
LV> and Setter) and another class has Action methods, listener methods for the
LV> navigation and listeners. But any online JSF resource that I check always
LV> have navigation, listener and getter setter methos in ManagedBeas which is
LV> a model.

Personally, I prefer your choice because it separates "view related"
model objects from purly "model related" model objects. More below.

LV> I would appreciate if you can suggest a best Design to follow for a simple
LV> functionality with 4 to 5 screens(JSF) and why? Do you suggest having a
LV> seperate controller / Navigation class for each JSF(Screen with in a single
LV> functionality)? I would recommend to go with one controller to have
LV> navigation / Listener methods and a bean with getter / setter methods and 4
LV> JSPs.

Hello Lalith and thanks for your interest. In the future, please send
such queries to webtier_at_glassfish.dev.java.net. I have Cc'd that list
for the benefit of others.

After meeting with a good portion of the JSF community last week at
JSFOne, I was reaffirmed in my belief that common usage of managed beans
falls into one of the following three categories.

1. Managed beans not related to the view layer at all.

2. Managed beans somewhat tied to the view layer by containing JSF listener
   methods.

3. Managed beans tightly bound to a specific page as a "backing bean"

Sounds like you have 1 and 2. Perhaps you want to have 1 and 3 instead?

Please followup to the list. Others have more battle-tested experience.

Ed