It depends, I would say. application scoped is great if you have one list for all users as Craig mentions, if you need to have a different list for each user, you would do it session scoped.
Often you will need to change the output depending on the language setting of the user, so you might end up with a session scoped list created for the current user with his language setting, just copied from an application scope map which contains the state lists in all languages. regards, Martin On 6/12/05, Muhammad Ikram <[EMAIL PROTECTED]> wrote: > > > So you are suggesting that the list of states should be application scoped > then? That would ensure it gets instantiated only once. right? > > K. > > > ----- Original Message ----- > From: Craig McClanahan > To: MyFaces Discussion > Sent: Saturday, June 11, 2005 11:51 PM > Subject: Re: Filling in select lists > > 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 > > > > > > >
