Thanks Simon,
I'll try the "saveState" approach... Regards, Matthias > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Auftrag > von Simon Kitching > Gesendet: Donnerstag, 22. Dezember 2005 22:13 > An: MyFaces Discussion > Betreff: Re: Restore View question > > > Hi Matthias, > > The app I'm working on has exactly the same issue; a "master" page with > input fields, and "immediate" links that take the user off to edit > "detail" records from which they can return to the main page. The > immediate is needed in order to not validate data in the main page > *yet*, but fields on the main page (which have never been pushed to the > model because of the "immediate" navigation) need to be re-rendered on > return from the details page. > > In this case I recommend binding components of the master page to a > backing bean *of request scope*, then using t:saveState to preserve the > backing bean (or just the bound references to components) as you > navigate to the details page and back. > > > So, my question is: when are component-binding components, or at > > least, their properties discarded? Does it only depend on the > > lifetime of the related backing-bean or any explicit modifications > > of the components? > > When a JSP page is rendered and a JSF tag is found which has a "binding" > attribute, that binding attribute is evaluated. > > If the result of evaluating that binding is NULL then the component is > created and the new component then assigned to the binding. This is the > "normal" case; the backing bean is a request-scope bean that has just > been created so the binding returns null, a new component is created, > and the new bean then gets told about the component. > > However if the bean returns an existing component, then that component > is used instead of creating a new one. This is what I'm suggesting: > saving the components into a backing bean, then ensuring the bean isn't > discarded at the end of the request by using t:saveState. When the > master page is re-rendered, the binding will return the old component > instance thus preserving its submittedValue etc. > > Instead of t:saveState, you could use a session-scope bean. However > session-state beans chew up memory - especially if they hold references > to UIComponent trees. It's a very difficult issue to ensure the memory > is freed up when no longer used. The t:saveState component makes that > memory management much easier; see the wiki entry for details. > > Regards, > > Simon > > > Martin Marinschek wrote: > > Matthias is absolutely right here. > > > > He can't bind the value to the backing bean, as he doesn't want > > conversion and validation to happen. Binding the component to a > > session bean sounds like an interesting solution - have never thought > > about this before... > > > > Conversion and validation with different buttons to happen and others > > not is actually a week point of JSF - I like what Mike and Jesse have > > done with their optional validation framework so far, though. But even > > with this framework, you can't do anything about conversion, right? > > > > Mike, you have soft converters, too, but if a string doesn't convert > > to a date correctly, you can't set it to the backing bean, right? > > > > regards, > > > > Martin > > > > On 12/22/05, Matthias Kahlau <[EMAIL PROTECTED]> wrote: > >> > >>> OK, now I'm lost ... why would you want to skip the update > model values > >> phase? > >> > >> Because I have to skip the process validations phase, so that > the user's > >> work flow isn't broken. The user just wants to edit some > details on a sub > >> form, and then return back to the main form. Validation of the > main form > >> should only occur at the end of the user's task, when he > presses the save > >> button on the main form. > >> > >> > >> > >> > >> On 12/22/05, Matthias Kahlau <[EMAIL PROTECTED]> wrote: > >>> Hi Craig! > >>> > >>> I think you don't mean the *value* attribute of the component > tag, because > >> as I know, this is not possible in my use case. The related > backing-bean > >> property won't be updated, since the update model values phase > is skipped. > >> The value entered is stored in the component (submitted or local value) > >> only. > >> > >> > >> > >> > >>> So what do you mean with "binding the *value* of the component to a > >> session bean property"? > >> > >> > >> Yes, binding the value property is what I was referring to.
