shale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <hermod.opstv...@dnbnor.no>
Subject RE: [dialog] Get rid of subdialogs
Date Thu, 24 Aug 2006 08:28:21 GMT
Hi

I agree with this. I would like to look at subdialogs as a sort of component, much like we
create a Clay component and reuse it in various pages/views. If we think of subdialogs in
this way, we should be able to configure the state/context going in and where to add state/context
going out.

I also would hate to have to declare the same sequence of views more that once. Being able
to declare a sequence once and reuse it wherever I want is most desireable.

Hermod

-----Original Message-----
From: David Geary [mailto:sabreware@gmail.com]
Sent: Thursday, August 24, 2006 5:46 AM
To: dev@shale.apache.org
Subject: Re: [dialog] Get rid of subdialogs


I agree that it's often useful for a subdialog to access data contained in a
parent dialog, or as SHALE-153 points out, vice-versa. Use cases where
subdialogs are entirely self-contained would certainly seem to be in the
minority.

OTOH, I don't think this necessarily warrants a change to subdialog design
because dialogs  have the mechanisms to deal with this. The starting state
for a subdialog can be an action state, and that method can set up the
dialog.data reference before entering the first view state.

What the dialog.data reference points to, and whether that object has access
to the data object of the enclosing dialog (or vice-versa) seems like more
of OO design issue that's separate from the dialogs themselves.


david


2006/8/23, Sean Schofield <sean.schofield@gmail.com>:
>
> 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
>


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR Group
cannot accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


Mime
View raw message