Is this discussion actually about managed beans or is "managed bean" being used in a "loose" sense?
On Apr 7, 2005 8:45 AM, Jonathan Eric Miller <[EMAIL PROTECTED]> wrote: > 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: <[email protected]> > 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 > > > >
