One thing to remember is that you are *not* limited to referencing a single backing bean. Using a request scope backing bean corresponding to the page is fine ... but quite often, the lists of select items are fairly constant, and you'd *really* like to build them only once, right?
In the Shale <http://struts.apache.org/shale> "use cases" example application, there is an illustration of the technique I prefer for this ... bind select lists to a property on an application scoped managed bean (if they are common to all users) or on a session scoped managed bean (if they are specific to a user). The example includes "select locale" use case, which includes a dropdown like this: <h:selectOneListbox id="locale" value="#{locale$select.locale}"> <h:selectItems value="#{domains.supportedLocales}"/> </h:selectOneListbox> where "locale$select" is my request scoped managed bean for this page, and "domains" is an application scoped managed bean that includes this method: public SelectItem[] getSupportedLocales(); Inside this method, you have a number of alternative strategies available ... and you can change your choice without callers having a clue :-). Consider among other options: * Lazily instantiating the list the first time someone calls this method. * Using a ServletContextListener to load up the appropriate data before the first request is received. * Either of the above two techniques, plus a timer thread to erase the cached value after a given amount of time (to pick up the changes that occasionally occur, without having to restart the app). * Either of the above two techniques, plus embedded logic that does a relatively cheap database access to determine whether the data has changed, and refreshes the list first. Doing this sort of logic on every request is quite likely a waste of resources. Strive to minimize the number of times you do things like "create a SelectItems array containing the 50 state abbreviations and names" :-). That's the sort of thing I would want to do just once :-). Craig McClanahan On 6/11/05, Richard Wallace <[EMAIL PROTECTED]> wrote: > I just thought that I should also mention that my backing bean is a > request scoped object. So another solution is to switch this to a > session based backing bean, but my backing bean is where the select > items for organizations, departments and contacts for the list boxes and > drop-down menus are generated. I would like to be able to cache those > for the life of the request but they shouldn't be cached across requests > since they could change at any time. > > What's the best practice for these backing beans? My design is pretty > much following the design ideas in a couple of articles I've read where > the backing bean contains the current selected object and the JSF pages > bind with value="#{contactHandler.currentContact.firstName}" for > example. Is it better to have this backing bean be session scoped or > request scoped? > > Richard Wallace wrote: > > > Richard Wallace wrote: > > > >> So what do I need to do to fix this? One idea is to try and find the > >> value that JSF will use in the form and use that if there is one and > >> then otherwise use the backing beans value when I'm generating the > >> department choices. Seems kind of hacky since that's one of the > >> things that JSF is supposed to do for you is provide the form > >> values. I'm also not certain how to get the values that JSF is going > >> to use in the forms without having it update the model values. > > > > > > Well, I figured this part out at least. I can use the > > FacesContext.getExternalContext ().getRequestParameterMap(), but then > > I'd need to know the key of the form and form element to be able to > > lookup the value. Obviously, not an ideal solution. > > > >> Another idea is if I can somehow avoid doing the validation some > >> other way. That's really the only reason I need to do the event > >> processing right away and then skip to the rendering phase. But I've > >> looked and there doesn't seem to be another way of bypassing validation. > > > > > > Well, I've looked around and this doesn't seem possible. Unless I can > > do something with PhaseListeners, but I don't see how. > > > > Please help! > > > > Thanks, > > Rich > > >
