shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 06:50:22 GMT
On 8/23/06, Sean Schofield <> wrote:
> I'm not quite convinced that <subdialog> is very useful as
> implemented.  I see the usefulness in stringing existing dialogs
> together but certain byproducts of subdialog are undesirable.  For
> instance, SHALE-153 which complains about how you can't easily access
> state information between a "parent" and "child" dialog.

I agree that, if we keep the concept of subdialogs around, mechanisms for
dealing with this are important.  From the perspective of a subdialog, you
should be able to "pull" data out of the parent dialog's context
transparently (WebWork/XWork do this with their action context method).
And, we would want to provide a way for a subdialog to "push" data up (at
least) a level as well.

I've discussed this with Craig before and IIRC he doesn't agree with
> me on this but I can't see how having subdialogs as "black boxes" is
> very useful.  Maybe there are some use cases out there but it would
> seem to me that its much more common that you would want to share
> state across two dialogs.

Agreed that the need to share state is important.  But, even without, you'll
see use cases like the one in the logon dialog of the Use Cases sample app
:-), where the wizard part of "Create A New Profile" and "Edit My Existing
Profile" are nearly identical, and should not have to be configured twice.

Here's a hypothetical example:  Suppose you have a e-commerce site
> where you sell both physical products as well as downloadable
> software.  You have the following "dialogs":
> shopping cart
> shipping
> payment
> download link
> Each of these "dialogs" represents a series of actions and views.  For
> the physical goods you might want to compose a "physical goods" dialog
> as follows:
> shopping cart -> shipping -> payment
> For the downloadable software you might want to compose a dialog that
> uses the same shopping cart and payment dialogs as in the physical
> goods case:
> shopping cart -> payment -> download link
> If you compose these using <subdialog> you immediately run into
> problems.  Your payment dialog has no access to any of the state
> generated by the shopping cart phase of the dialog.  As a developer I
> don't want shopping cart and payment to be black boxes, I want them to
> work seamlessly together.  I also don't want to configure the shopping
> cart and payment stuff twice in order to avoid this.
> I think the ability to plug dialogs into one another is really cool
> but in the past I have found myself doing various hacks and
> workarounds to get at the state information further down the stack.
> Of course we could make it optional to create a new state for the
> subdialog but there are other reasons not to bother with this.  I have
> implemented my own prev, next, ok button scheme on top of shale
> dialogs and subdialogs significantly complicate this.

Sharing the parent's context object (I'm leaning towards migrating to
"context" instead of "state" for this concept, because it seems more
consistent with various published discussions of the idea) is an interesting
idea -- but it seems like you'd run the risk of name collisions if the child
dialog happened to store something under name "foo" for its own use, without
being aware that "foo" was also in use by the parent dialog.  An appropriate
nesting technology for pulls, and some manner to deliberately push data for
pushes, should be able to deal with this, though.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message