Simon,
The problem I face with the saveState component, is that when I place it
on the master (1st) page, it is, as expected, initialized with no value
(because the user has yet to click on a row in the datatable to edit a
user/item.)
Once the user click on a row, the detail page is displayed. But the
BackingBean is reloaded from the saveState component, and is set as
empty (as it was on the master page) -- and not initialized with the
data from the row the user has clicked on.
What I would need is somehow to modify the saveState component before
the detail page is displayed so that I can modify the backingbean inside
and put one correctly initialized (corresponding to the row the user has
clicked on).
This seems like a basic app, but I cannot get around it without using
session scoped bean. I would be very welcome if anyone could show me
some code with request scoped beans achieving the same results.
Thanks!
> <t:saveState> is the correct tag to use when you want to avoid
session-scoped managed
> beans.
>
> I don't know why you have that command-link code; nothing like this
is necessary to use
> t:saveState. If you wish to preserve the state of an entire managed
bean, then do:
>
>Master page:
> <t:saveState value="#{myBackingBean}"/>
>
> Detail page:
> <t:saveState value="#{myBackingBean}"/>
>
> On first visit to the master page, there is no saved state to
restore, so a default instance
> of that bean is created. When the page is serialized after rendering,
the bean's state is
> stored.
>
> When either the master or detail page is visited thereafter, the
saved object is recreated
> from the saved state, and #{myBackingBean} is set to be a reference
to the restored
> object.
>
> You can also save just specific fields of a bean via:
> <t:saveState value="#{myBackingBean.someProperty}"/>
>
>Regards,
>
>Simon
