On Apr 6, 2005 10:08 PM, Ray Clark <[EMAIL PROTECTED]> wrote:
Are the sub application beans actually managed beans?
Or are they kept as class variables in the master
application bean?
--- Heath Borders <[EMAIL PROTECTED]> wrote:
> Here's the way we've done it:
>
> Our app is mainly for data collection. Usually, its
> just a big master-detail
> wizard, but sometimes its more complicated.
>
> Let's start with a simple example. I have an
> application that lets users
> input organization information. The users start by
> selecting an Organization
> from a <h:selectOneListbox />. Then, they proceed to
> a page where they can
> enter a description and tax id for the Organization.
> Next, they go to an
> address editor, where they can add multiple
> addresses. Then, they go to a
> phone editor, where they can editor multiple phones.
> Finally, they go to a
> page where they can choose Organization types from
> an <h:selectManyCheckbox
> />.
>
> The way I chose to approach this problem is to have
> one master application
> bean and multiple sub-application beans. The master
> application bean
> contains all the common information for all the
> pages of the app. In this
> case, its just the Organization the user selected
> from the list. The master
> bean also contains all the sub-application beans,
> one for each page. So,
> there is an OrgSearch bean for the first page, an
> OrgGeneral bean for the
> second page, an OrgAddresses bean for the third
> page, an OrgPhones bean for
> the 4th page, and an OrgTypes bean for the 5th page.
>
> The subapplication beans are setup so that they are
> constructed when the
> master bean is constructed, and are passed a
> reference to that master bean.
> That way, they can access common information. This
> setup provides good
> separation, and also good sharing.
>
> On Apr 6, 2005 8:41 PM, Ray Clark
> <[EMAIL PROTECTED]> wrote:
> >
> > 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
> >
>
>
>
> --
> -Heath Borders-Wing
> [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
--
-Heath Borders-Wing
[EMAIL PROTECTED]
