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
