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]
