I understand all that you've said and am using some application scoped
beans for global select items that don't change. The problem is that
the list of items that I'm working with now are database backed and are
likely to change often. I can maybe cache the top level select list
items, the organizations and update it when an organization is added or
updated. But the others, the list items for departments and personnel
are dependent on the selected organization so there's no way to cache
them.
What about my other questions? When the second select list, the
department, selected value changes and the page is submitted for
immediate event handling, it seems the only way to avoid validation
_and_ have the selected organization set in the backing bean is to
lookup the value myself using the
FacesContext.getExternalContext().getParameterMap(). Is there a better
way to accomplish this?
Thanks for the feedback,
Rich
Craig McClanahan wrote:
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
