On 2/12/07, Simon Kitching <[EMAIL PROTECTED]> wrote:
Michael Litherland wrote:
> Sorry about not being clear. I have a dataTable that renders a
> ListDataModel created by a request scoped bean. I understand that
> keeping the DataModel request scoped would make it not work on the
> return click, so as a result I tried to tie it to a session scoped
> 'user' bean that is a managed property of all the request beans in
> question. However a command link that called an action of either the
> source request bean or the target request bean resulted in reloading the
> source page as if there was no from-outcome rule for the page given the
> action that I specified (and I tested this by using log4j to log the
> method that I wanted called). I could diagram this or provide some
> pseudo code if that would be helpful.
Do you have an h:messages tag in this page? Normally "failed to
navigate" problems are caused by validation failure.
Yes I do have a h:messages and copious log4j logging, but it doesn't display
any problems, which in itself is worrying.
A more elegant solution is to put the model into a "conversation
scope"
> of some sort; t:saveState is one way to do this.
>
>
> I'll look into this, thanks for the hint.
NB: Apache Shale provides a "conversation scope" feature, and so does
JBoss Seam. Both are more powerful than t:saveState but also more complex.
Hopefully someday "conversation scope" will be part of the JSF standard
as it's basically impossible to write a decent-sized app without it.
Haven't really looked into shale, but steam is too much integration for my
taste and gets away from the relatively XML-free nature of JSF/EJB3 (not
that XML is bad, but expression of the logic in code is ideal for
maintenance going forward). That idea sounds like what the pageFlow portion
of tobago is going for and I agree that it's a great idea.
> 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.
>
>
> Don't know about this one, eventually that datamodel may have 600+ paged
> entities and that kind of freaks me out. Of course that's another
> obstacle on its own.
Yep, something to be careful of. However t:saveState has effectively the
same implication, as does any other conversation-scope solution OR using
session-scope beans. In all cases, the data is kept around until the
user decides to do a postback or the session times out. Of course with
session-beans there is an additional task of figuring out when to
discard data, which "conversation scope" does for you.
Note also that permitting users to use "back" buttons makes things
really ugly. If the table state is embedded in the component tree
(t:saveState or t:dataTable's native preserving) then this works but the
memory implications can be nasty for large models. If the data is kept
separate then a back-button causes mismatch between table and model.
Fortunately for this app the "users" are in themselves developers so I have
the option of saying "back is bad, mmkay?" but I agree that it's an issue
with app development in general (boy do I hate the web sometimes, but really
any serious multiuser app has to deal with it).
> 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.
>
>
> In this case the data for the model won't likely change (additions are
> infrequent). I understand the concern here.
Then refetching the data on postback is probably the best solution.
I'll keep playing when time permits (this is one of those 'it must be
complete by tomorrow' (quite literally) apps), but it still seems to me that
dataTable may have issues. I'd like as badly as anybody to be able to
determine if its my app or the library's issue, hence my call for assistance
here.
Cheers,
Simon
Again Simon, thanks for your reply.
Mike
