Return-Path: 
 <dev-return-37193-apmail-struts-dev-archive=struts.apache.org@struts.apache.org>
Delivered-To: apmail-struts-dev-archive@www.apache.org
Received: (qmail 77258 invoked from network); 1 Sep 2005 13:25:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 1 Sep 2005 13:25:10 -0000
Received: (qmail 5540 invoked by uid 500); 1 Sep 2005 13:25:03 -0000
Delivered-To: apmail-struts-dev-archive@struts.apache.org
Received: (qmail 5491 invoked by uid 500); 1 Sep 2005 13:25:03 -0000
Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@struts.apache.org>
List-Help: <mailto:dev-help@struts.apache.org>
List-Post: <mailto:dev@struts.apache.org>
List-Id: "Struts Developers List" <dev.struts.apache.org>
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Delivered-To: mailing list dev@struts.apache.org
Received: (qmail 5478 invoked by uid 99); 1 Sep 2005 13:25:03 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 06:25:03 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of sean.schofield@gmail.com
 designates 64.233.162.205 as permitted sender)
Received: from [64.233.162.205] (HELO zproxy.gmail.com) (64.233.162.205)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 06:25:17 -0700
Received: by zproxy.gmail.com with SMTP id j2so111431nzf
        for <dev@struts.apache.org>; Thu, 01 Sep 2005 06:25:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=jAkNWINsdiokPAezsVuqOQbO1rYMeineyjfr8B88LvA51qvX8Mb4hAHKVEXNLJ+6uVZd19pS7rHxSfcf9nNwIpB2+jWPi5hILsQe+vqnUKdR7maxGaJCD0dfSqHXKvDpDdMdHZRWbrhuFrrqC5KXYDtg3IHkYvLZJm6YLhghwE0=
Received: by 10.36.129.1 with SMTP id b1mr1245598nzd;
        Thu, 01 Sep 2005 06:24:49 -0700 (PDT)
Received: by 10.36.252.70 with HTTP; Thu, 1 Sep 2005 06:24:47 -0700 (PDT)
Message-ID: <2387fbc50509010624407525ac@mail.gmail.com>
Date: Thu, 1 Sep 2005 09:24:47 -0400
From: Sean Schofield <sean.schofield@gmail.com>
To: Struts Developers List <dev@struts.apache.org>, craigmcc@apache.org
Subject: Re: [shale] Why does <subdialog> data disappear when terminating?
In-Reply-To: <f8b39ace0508311504151612a1@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <2387fbc50508311437162ea1a@mail.gmail.com>
	 <2387fbc505083114534f6e17e6@mail.gmail.com>
	 <f8b39ace0508311504151612a1@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

> The motivation for getting rid of the data at the end of a subdialog is
> twofold:
>=20
> * 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.
=20
> * 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?
=20
> In particular, can't you ensure that an action state prior to the exit st=
ate
> 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.
=20
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