myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McGrady <michael.mcgr...@gmail.com>
Subject Re: Managed Bean OO Design question
Date Thu, 07 Apr 2005 15:58:01 GMT
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 <jemiller@uchicago.edu> 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" <rcc1234567@yahoo.com>
> 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
> >
> 
>

Mime
View raw message