Bart Kummel wrote:
Hi Bart,
What do you use as the Trinidad replacement for t:savestate, as a method to
cache request-scoped beans on the same page? E.g., to avoid the need for
another database roundtrip in postback or redirect requests.
I know pageFlowScope, but it is more inconvenient to use and has also a
slightly different focus, AFAIU.
The pageFlowScope is *the* alternative for<t:savestate>. I don't see why
pageFlowScope is less convenient.
As far as I understand, with pageFlowScope, you have to care for
the lifetime of your beans yourself in your Java code. I.e., one
has to call clear() or remove() when the bean is not needed any more.
For the use case of communicating between pages, this might be OK.
For the use case of keeping a request-scoped bean cached in the
*same* page (e.g., because it needs a database round-trip to get
the data), it's very inconvenient. If the user leaves such a page
with t:savestate and changes to an other application part, my bean
is gone eventually. With pageFlowScope, I have to take care *in
that application part* to invalidate my bean, and that coupling of
view and model is bad, IMNSHO.
Let me present a simple example: An app with two pages,
1) a list page with items from a database. Every time that page
is »entered«, the list should be retrieved anew. In the page,
there are actions to sort or filter the list. Using these
actions is not considered »entering the page«, i.e., for these
actions, the list last retrieved should be used. (These are
operations on the list, not on the database content.)
2) An entry page where you can enter a new item for this list.
With t:savestate, I would have the list bean persistent in the list
page, but not in the entry page.
How to do this with pageFlowScope? It's clear that I want neither
session-scope nor request-scope for my item list bean. It's easy to
put the list into pageFlowScope the first time I enter the list
page. But then, I have to remember to remove the list bean *in any
action* where I leave my list page.[*] Respectively, I have to add
my own pageFlowScope bean management code to a PhaseListener, to
not duplicate that code.
Or, where do I get this wrong, and where is the simple design
pattern to handle that use case? (Which is, actually a very common
use case in the apps that I'm writing currently, although with a
bit more complex action relationships.)
Any comments would really be appreciated,
Joachim
[*] I'm aware that this example is too simple to show the use case
exactly. Here there is only one action to fill the list bean, and I
could simply leave it in the pageFlowScope until it is reset by the
next call of that action. But in practice I have more complex
action relationships. So I'm looking for a solution that doesn't
clutter pageFlowScope with lots of beans that are not in use any
more by the current dialog state. IMHO, that's just good
programming style; otherwise I could often use session-scoped
beans. That's the beauty of t:savestate as I see it: For the use
case above, it keeps my active set of beans clean without me having
to write Java code.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: [email protected]
Roedermark, Germany
