shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Schofield" <sean.schofi...@gmail.com>
Subject [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 03:02:07 GMT
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'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.

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.

Sean

Mime
View raw message