IMHO, Heather's approach makes quite sense whenever session size is not a problem (as commented). The idea is just to inject the sub-beans into the main bean using Dependency Injection. I strongly recommend you to take a look at Spring framework and its integration with JSF (maybe just the DelegatingVariableResolver will fulfill your needs here).
Anyway, I think that if session management is a constraint for whatever reason, you may change the scope of beans to request, although having always in mind that information between 2 different request-scoped beans must always be shared using the session. The division could correspond to the different use cases you may find in your application. Don't worry if you call one bean from another bean, as JSF will make sure that you always have the reference to the bean whenever you need it. Furthermore, you can save state on the client using JSF ;-) On Apr 7, 2005 4:22 PM, Duong BaTien <[EMAIL PROTECTED]> wrote: > Hello: > > Have you looked at Struts-shale that give you DialogBean (session scope) > which control the flow of different pages and ViewController (request > scope) which can pull data from other beans and control the current page > request? > > I found DialogBean very useful even in the case you do not need to > control the page flow. Shale has facilities to further extend Jsf and > enable finer control. > > BaTien > DBGROUPS > > Heath Borders 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] > > <mailto:[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] <mailto:[EMAIL PROTECTED]> > >
