Thanks for the quick answer and explainations! Beeing not very comfortable
with jsf phases (shame on me!), I decided to keep searching and I found
something very interresting which solved my problem and sounds like a clean
way to use the framework. Here's my information source:
http://mail-archives.apache.org/mod_mbox/myfaces-users/200612.mbox/[EMAIL
PROTECTED]<http://mail-archives.apache.org/mod_mbox/myfaces-users/200612.mbox/[EMAIL
PROTECTED]>
...using my table bean in a "request" scope solves the serialization problem
while still making navigation work. Using the method described in this link
allows the control of data exchanged by pages using the pageFlowScope (oh my
own Beans). Problem solved!
Thanks for the help!
On 5/30/07, Chris Lowe <[EMAIL PROTECTED]> wrote:
Hello,
I think that quote came from me, which is a bit of a coincidence as I only
just switched from the old trinidad mailing list to myfaces a few hours ago.
To be honest, I've not used table pagination or server clustering so I'm
not even certain if the technique will work for you. However here is
(hopefully) a better explanation...
The quote basically means:
Store your table data in a list rather than a DataModel. So when you call
getSomeDataModel() instead of using a cached instance of the DataModel that
is saved against the page bean, create a new instance each time and populate
if from a cached *list*. There is one problem to this and that is when a
user clicks on a link in the table, then at INVOKE_APPLICATION the table's
data model needs to work out which row was clicked. To do that properly it
needs a DataModel instance that was based on exactly the same list that was
used at time when the page was rendered. Otherwise it can't find the row and
you're table action may not be called. Hence use a cached version of list at
RESTORE_VIEW.
Later, if your table action results in the data model being changed then
you want the table to show the current data. Reusing the cached list is no
good at this point since the table action may have deleted instances
or items may have been edited etc. So refresh the list and store to cache
so that getSomeDataModel() will have an updated list when it is called
during RENDER_RESPONSE.
in pseudo code this translates to something like (it's been a while since
I looked this):
DataModel getSomeDataModel() {
return new DataModel(getList());
}
List getList() {
return getSessionBean().getCachedList();
}
// does your page backing bean have a method of getting at JSF lifecycle
events? E.g. in Java Studio Creator you get this:
void beforePhase(PhaseEvent evt) {
if (evt.getPhaseId() == PhaseId.RENDER_RESPONSE) {
List list = refreshList();
getSessionBean().setCachedList(list);
}
}
Hopefully that helps?
Cheers,
Chris.
On 5/30/07, Stéphane Poirier <[EMAIL PROTECTED] > wrote:
>
> Hi,
>
> My problem is simple, yet I can't solve it : I have 2 pages in my web
> application. "Page 1" contains a <tr:table/> with page navigation (a
> scroller) with items. Clicking on a item leads to "Page 2" which displays
> the detail of the clicked item. A bean is associated to each page. I used to
> store the DataModel in my "Page 1" Bean and to fetch the current row
> (getRowData) in my "Page 2" and display the data. The problem is the my
> cluster requires serializable components... DataModel is not.
>
> I've seen a plenty of solutions but they are not detailed enought for me
> to understand how to implant them. I would like to know the "right" way to
> do this.
>
> A solution I've heard of (not clear enought for me):
>
> > > A general JSF solution to this would be to store your data model (or
> > > whatever collection that drives the datamodel) in a session bean which
> > will
> > > serve as a data cache between requests. In the restore view phase - use
>
> > the
> > > cached version; in prerender phase refresh the cached list. It ain't
> > pretty
> > > - but it worked for me.
>
>
> Thanks in advance!
>
