Michael Litherland wrote:
Hi all,
I'm doing some pondering about bean scope and in particular if dataTable
is working the way it's intended. I've tried both the myfaces and
tomahawk dataTable entities and if they're filled with a request scoped
bean wielding a DataModel putting a commandLink or button in the table
to provide a detailed view of a row just causes a page reload rather
than going to the action I specify. From a considerable amount of
google it seems this is a feature of JSF, but I find that hard to
believe, even if the RI is doing it too. I've also tried playing with
binding and doing downright evil stuff in my faces-config.
So first off I apologize if this is a well trodden path in faces
discussions. If you don't mind, how do others deal with this? I can't
see making all the backing beans session scoped (though it works), and
tobago's pageFlow stuff doesn't seem practical now (and I don't even
know if it would help).
Putting a command link or button in a table certainly works; I've done
it many many times. There should be an article on the wiki
(wiki.apache.org/myfaces) that describes how to do this "master/detail"
stuff but it appears that the apache wiki is down right now.
You don't describe exactly what is happening at your end so I can only
speculate what the root problem is, but I wonder if your problem is that
on postback your datamodel is empty. This would fit with your second
paragraph where you talk about bean scopes.
It's a fundamental assumption of JSF that when a page containing a table
is posted back to the server the datamodel used to render the table is
available (or one with identical data).
NB: Currently, MyFaces requires this even if the table contains no input
or command components (well, it calls the model getter anyway). I'd like
to see MyFaces skip fetching the model in this case but that's another
issue.
The brute-force solution to making the data model available is indeed to
put your backing bean in session-scope.
A more elegant solution is to put the model into a "conversation scope"
of some sort; t:saveState is one way to do this.
The t:dataTable has a "preserveModel" attribute or something like that
which automatically handles this but does require the datamodel to be
serializable so it can be stored with the component tree.
If the datamodel is actually backing some data that you know does not
change between render and postback (eg is static data from a database)
then the datamodel can be safely refetched during the postback
processing. However if the data can change this is a really bad idea as
JSF will get confused about which row is which.
Regards,
Simon
