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.
