> The motivation for getting rid of the data at the end of a subdialog is
> twofold:
>
> * Simulate a scope "longer than a request but shorter than a session"
> so that the application doesn't have to explicitly manage the cleanup
> (since the servlet container does not provide such mechanisms).
No problem with that goal and I believe you have accomplished this
with get/setData in Status.
> * Treat a subdialog as a black box rather than something I can sort of
> peer into and then pull out results.
Personally, I don't see the advantage of this. I thought the point of
subdialogs was to resuse a dialog as part of another dialog. If this
is the goal, then why would I want to interrupt this "scope" just
because a subdialog ended?
My only theory is that the dialog that is being used as a subdialog
does not know that it is a subdialog so it needs to cleanup after
itself. Is this right?
> In particular, can't you ensure that an action state prior to the exit state
> of the subdialog caches away anything you want to save? That puts the
> responsibility on the subdialog, instead of the caller of the subdialog, to
> do "post processing".
There are workarounds for sure but it seems like a lot of hassle for a
common use case. The only place where it makes sense to cache this
information would be in the parent dialogs state.
Here's a hypothetical use case: You are doing an online order through
a series of dialog screens. Suppose also that you have a CreditCard
dialog that you want to use as a subdialog in a couple of different
dialogs. After the user enters there credit card information you
still have more steps to go, so where would you put the credit card
information? I'd rather have it in #{dialog.data} so that when the
user confirms they want to order, then we can use all of the
information to process the order. IMO it doesn't make sense to do
anything with this information until that point.
Anyways, I really like the dialog stuff but as I get more experience
with it, this is one of those things that puzzles me.
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
