The way that I've been doing it is that I usually just have one bean named something like CourseRegistrationHandler, if it was for an application that handled registering for courses. I would make that bean a managed bean stored in session scope. Then, I would have other data objects stored within that bean and the JSF components would be bound to those. For example, I might have an object respresenting a course called Course and then an object in Course called Section, etc. I found that it definitely helps to get the data objects modelled correctly and to get the relationships setup properly. Otherwise, you could have to go back and make a lot of changes after the fact if you try to do it in a more quick and dirty way. I'm using Hibernate as a persistent service which helps keep the code nice and clean (no SQL all over the place). So, basically, I have my application logic in the handler bean which is the glue between the JSF UI and the data objects.

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 experienced
JSF 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




Reply via email to