I have one application that is a little more complicated which is a reservation system. There are three main types of objects that a user can manipulate: items, reservations, and users. So, in that application I have ItemHandler, ReservationHandler, and UserHandler managed beans that are stored in session scope.
I don't know if this is really the recommended way of doing it. It's worked OK for me so far, but, I don't know how it would hold up if you had a really complicated application.
I've been wondering the same thing: if one should have a different bean for each page for storing things like data that is put into drop-down lists and the like.
I'm also not sure exactly what the recommended naming conventions are. I got the idea of using the "Handler" naming convention from Hans Bergten's JavaServer Faces book. To me, "Handler" makes more sense that "Bean." Personally, I think suffixing anything with "Bean" is pretty pointless as it doesn't say a lot.
One issue to watch out for if you have a wizard-like application is for session expiration. I created a Servlet filter to handle this. It checks to see if the browser provided a session ID that is invalid and if it's present, it redirects to whatever page you configured it to go to. For example, a page that notifies the user that their session has expired, or make it go back to the first page of the wizard process. The filter that I have is a little more complicated than that though because I made it so that it works if you are using Tomcat integrated security too. In that case, I had to make it so that the session expiration check was in the login page and then set an attribute that the filter would look for and clear. Does anyone know if this is the kind of thing that Shale does? When I first started using JSF, I thought to myself, JSF should make this easier. It's not that bad now that I have it working, but, it took me awhile to refine it to the point where it works well.
Another issue to potentially watch out for if you have a wizard-like application is what happens if a user skips pages? Originally, I had a filter that did some checks on this, but, now, I just do validation at the last step to make sure everything is filled in correctly at that point, otherwise, it redirects to page 1. Sorry for rambling on so long. These are just issues that I've run into. I don't know if how I've solved them is the way everyone else has or not.
Jon
----- Original Message ----- From: "Ray Clark" <[EMAIL PROTECTED]>
To: <myfaces-user@incubator.apache.org>
Sent: Wednesday, April 06, 2005 8:41 PM
Subject: Managed Bean OO Design question
I've been on this list for awhile now and I don't remember a discussion about how to architect managed beans for a page. (Please bear with me as this has turned into a rather long post.) I see 2 alternatives with how to set up the classes for my managed beans.
First, for sake of discussion, here is my problem set. On my page I have 2 selectOneMenu lists and 1 dataTable. The first selectOneMenu is a list of subjects, the second is a list of teachers, and the dataTable is a list of classes. Selecting the subject and teacher determines which classes will be displayed in the list of classes. The list of classes is displayed when the search commandButton is clicked.
Now, the question is, do I have just 1 managed bean for the page? That bean would have as a class variables, a teachers list, a selected teacher String, a subjects list, a selected subject String, and a classes list. Then for methods it would have all of the getters and setters for these fields in addition to the method for the commandButton. The method for the commandButton would call the business layer to actually retrieve the list of classes from the data layer. The getter for the teacher list would call the business layer to actually retrieve the list of teachers, etc.
I could have another page in my app (or another app), that needs an inputText field for a teacher, and possibly a method to validate the name entered to see if it was valid.
So with this design managing of teacher information would be spread across multiple beans.
Or, do I have 1 managed bean per object. So I would have a managed bean to manage teacher information, a managed bean to manage subject information, and a managed bean to manage class information.
This would group all of the presentation for an object into 1 class, but it causes complexity when one class needs access to the information in another class in order to retrieve its data. It also seems to make the managed bean organized more like the data layer than the presentation layer.
In either case, the managed bean would just be for passing the data to the JSF page and for calling the business layer to retrieve, maintain, etc, the data.
I like aspects of both designs.
Maybe there is another better solution. I have just been learning the tags and haven't given much thought to the design of the beans yet. But it's time for me to start thinking about how to set up my managed beans, hence I am asking for your advice.
From an OO perspective, which way do you experiencedJSF programmers have things set up?
Thanks, Ray
__________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail