> -----Original Message----- > From: Richard Wallace [mailto:[EMAIL PROTECTED] > Subject: Re: Filling in select lists > Korhonen, Kalle wrote: > >Looks to me that you should use x:saveState to extend the > lifetime of > >the request scoped bean and/or to save the specific > properties of the > >bean - unless there is some specific reason why you are avoiding the > >use of x:saveState? > I didn't know it existed. I've looked at some of the > examples on its use and I'm still not sure exactly what it > does. It's not very well documented from what I've been able > to find. Care to fill me in on the details of how to use it > and what it does?
With x:saveState you can store a value an object/property and restore it using the same id, i.e. on "edit user" page you have x:saveState id="editedUser" value="currentUser" (if currentUser is the name of your user bean). Then on "confirm user changes" page you use the same tag to restore the changed bean. The same goes for saving bean properties. Play with it and see how it works. Kalle > >>-----Original Message----- > >>From: Richard Wallace [mailto:[EMAIL PROTECTED] > >>Sent: Sunday, June 12, 2005 12:33 PM > >>To: MyFaces Discussion > >>Subject: Re: Filling in select lists > >> > >>Martin Marinschek wrote: > >> > >> > >> > >>>have you tried to set the "immediate" attribute on the > >>> > >>> > >>ui-input component? > >> > >> > >>> > >>> > >>> > >>> > >>Yes. I have immediate="true" set for the <h:selectOneMenu> > elements > >>and in the event handler I have it updating the selected value and > >>then jumping to the renderResponse() phase to bypass > validation. The > >>problem is that the backing bean is request scoped and the > previously > >>set value for the first <h:selectOneMenu> does not get set again in > >>the backing bean. > >> So the only way I can think to get that value is to use the > >>getExternalContext().getRequestParameterMap(). Here's the > JSF tags so > >>you can get a better idea of what is going on cause I don't > think I'm > >>getting my thoughts across very clearly. > >> > >> <h:panelGroup> > >> <h:outputLabel for="organization" > >>value="Organization" /> > >> <h:selectOneMenu id="organization" > >>value="#{courseHandler.selectedOrganization}" > >>valueChangeListener="#{courseHandler.handleOrganizationChanged}" > >>onchange="submit()" immediate="true"> > >> <f:selectItem itemValue="" /> > >> <f:selectItems > >>value="#{organizationHandler.organizationChoices}" /> > >> </h:selectOneMenu> > >> </h:panelGroup> > >> <br /> > >> <h:panelGroup> > >> <h:outputLabel for="department" > >>value="Department" /> > >> <h:selectOneMenu id="department" > >>value="#{courseHandler.selectedDepartment}" > >>valueChangeListener="#{courseHandler.handleDepartmentChanged}" > >>onchange="submit()" immediate="true"> > >> <f:selectItem itemValue="" /> > >> <f:selectItems > >>value="#{courseHandler.departmentChoices}" /> > >> </h:selectOneMenu> > >> </h:panelGroup> > >> <br /> > >> <h:panelGroup> > >> <h:outputLabel for="instructors" > >>value="Instructors" /> > >> <h:selectManyListbox id="instructors" > >>value="#{courseHandler.selectedInstructors}"> > >> <f:selectItems > >>value="#{courseHandler.contactChoices}" /> > >> </h:selectManyListbox> > >> </h:panelGroup> > >> > >>Now the selectItems for the department depend on the > selected value of > >>the organization and the selectItems for the instructors > list depends > >>on the selected value for the departments. What's > happening is that > >>when a user selects the organization the department list gets > >>populated just fine. When they select the department, the > instructors > >>list gets populated fine, but the departments list comes up empty > >>because the value for the organization is never set in the backing > >>bean because the update model phase is also bypassed. > >> The only ways I can think to fix this is to make the backing bean > >>session scoped so that the selected organization is > persisted across > >>requests. But that makes me nervous cause it seems error > prone. The > >>only other way to do it is to use the > >>getExternalContext().getRequestParameterMap() and lookup > the value for > >>the selected organization in the > >>handleDepartmentChanged() event handler. But that seems like a bad > >>idea because it means I have to know the id of the element ahead of > >>time, which I think is just sloppy design. > >> > >>I'll probably wind up switching to a session scoped backing > bean if I > >>have to. But that raises all sort of other problems in other areas > >>that I'm not entirely sure how to work around. I guess I > could move > >>stuff that needs to be request based like the dynamic > choice elements > >>to be request scoped and keep the current working object session > >>scoped or something like that. > >> > >>Does that sound like a decent approach or is there a better way? > >> > >>Thanks again, > >>Rich > >> > >> > >> > >>>regards, > >>> > >>>Martin > >>> > >>>On 6/12/05, Richard Wallace <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>> > >>>>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 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> >
