Re: [shale] Why does data disappear when terminating?

[Craig McClanahan <cr...@gmail.com>]

On 8/31/05, Sean Schofield <se...@gmail.com> wrote:
> 
> Oops. Sent to MyFaces instead of Struts. Sorry.
> 
> ---------- Forwarded message ----------
> From: Sean Schofield <se...@gmail.com>
> Date: Aug 31, 2005 5:37 PM
> Subject: [shale] Why does <subdialog> data disappear when terminating?
> To: MyFaces Development <de...@myfaces.apache.org>
> 
> 
> Craig,
> 
> I was wondering about the decision to "pop" the data when a subdialog
> ends. I'm sure there are use cases where this would be helpful but I
> can think of some where this is a major PITA.
> 
> My use case is that the dialog is running in a seperate window and
> eventually the date from my dialogs needs to be dumped back to the
> javascript object. Basically I am binding to #{dialog.data} with all
> of my fields but I'm not really updating anything in the database
> until after the dialog terminates.
> 
> What about making it an option to retain the same data object for all
> positions in subdialogs?


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).

* Treat a subdialog as a black box rather than something I can sort of
peer into and then pull out results.

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".

Craig

sean
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

Re: [shale] Why does data disappear when terminating?

[Craig McClanahan <cr...@gmail.com>]

On 9/1/05, Craig McClanahan <cr...@gmail.com> wrote:

> 
> 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).
> 

Of course, right after I pressed Send I thought of an even clearer way to 
look at it ... the state object of a subdialog is like the local variables 
stack of a method call that is currently in progress. It's contents are 
visible *within* that subdialog/method, but not outside.

Craig

Re: [shale] Why does data disappear when terminating?

[Craig McClanahan <cr...@gmail.com>]

On 9/1/05, Sean Schofield <se...@gmail.com> 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

Re: [shale] Why does data disappear when terminating?

[Sean Schofield <se...@gmail.com>]

> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org