On 9/1/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> > 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?
It's like the difference between reusing common code by refactoring it into
a separate method, and calling it, versus reusing common code by
cut-n-paste. I prefer the former :-). Incidentally, this aspect of dialog's
design came straight from Spring WebFlow, which draws the same sort of
distinction (although they manage per-webflow state quite a lot
differently).
> 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.
The "documented public interface" of a subdialog should include information
about what scoped attributes it provides to contain the result data it
produces (a validated credit card number in your case). Exposing the
subdialog's state object itself, directly to calling dialog's code, IMHO
will lead to undesireable coupling between the business logic of the caller
and callee dialogs.
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
>
Craig
