>>>>> On Wed, 03 Sep 2008 22:42:39 -0400, Lalith P Vaka 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
Hello Lalith and thanks for your interest. In the future, please send
such queries to firstname.lastname@example.org. 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
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Looks like I have confused the question.
Let me try again.
If I have a Form submit functionality with 4 or 5 screens (Form is so big, so we have to do it in 4 pages), each screen has few buttons (Next or back etc) and some validations, then should we have to follow One JSF tied one Backing Bean class for the UI / Control layer which means in my example I have to create 4 JSPs and 4 backing beans? or should we have to create 4 JSPs and One Backing Bean and One Controller class?
I have designed to go with the second approach.
1. Form submission is one single functiona though it has multiple screens.
2. Keep all the controlling (next or back)) / listening logic (Value change) in one place..Even though FacesServlet is the controller in JSF, we extend that functionality by writing some Action methods and some listener methods which decides the Navigation.
3. Keep all the setter getter methods in a seperate Bean.
4. Keep all the validation / Exception logic seperate
Which will give 4 JSFs, 1 Controller Class and 1 Backing Bean for this entire function.
I would appreciate any recommendations from Designers or Architects
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.