Yeah, this is what I was going on about in my post. Lots of hoops on
the front end to do something that seems conceptually simple.
I think updating several rows at the same time, which might require
local copies of the data, and just linking are two different things.
They might need two different components.
At a broader level, I was surprised that such a simple problem was
"solved" in JSF in this manner. It just seems so complicated, and as
I've seen, fairly error prone. And, forget the back button.
Again, not trying to knock JSF or the good people on the mailing list
here, but there's got to be a simpler way to do this. Personally I'm
probably going to use the hybrid approach I outlined in a post of mine...
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=82&t=000422
I think its the best of both worlds. I'm quite sure that people will
disagree, but I can't get past the complexity of the table of links in JSF.
Thanks
Rick Reumann wrote:
On 8/30/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
With this, the dataModel of the list is serialized to the client (in
the component state) and will be used for all phases on the postback
until rendering response comes into place - then the new data-model
will be fetched from the database.
So if you enqueue an action and wander off to the detail page, the
data will not be fetched again. Caveat: the dataModel is serialized to
the client. If you don't like the memory wasted in your session in the
meantime, this is a fair solution.
I wonder what your solution would be? I mean - you have to store the
information at some place if you don't want to go back to the
database?
Have your persistence layer cache it if you really need caching.
iBATIS, hibernate, they all can take care of this. I think it's so
much messier to have to worry about all of this 'state storage of the
data model' on the front end side. Make a call to the backend to get
your collection each time you need it. If you need caching, turn it on
on the persistence layer level. Why do so many seem to be against
this? It's clean, simple, efficient and easy to understand the
process. The only time I can see the need for keeping the 'whole data
model' around is when doing a master/detail update of a bunch of rows.
