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 -----
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
>
>
>
|
