You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Wilfred Springer <Wi...@Sun.COM> on 2005/09/22 10:26:59 UTC
[shale] Dialog Manager
All,
Let me start by saying that I *really* like the dialog mechanism in
shale. Dialogs as first-class citizens have been on my wish list for
quite a while, and now we have it. Totally cool.
At the same time, I have to say that some of it feels a little bit
uncomfortable and I mean the exit mechanism in particular.
This is what http://struts.apache.org/shale/ says about it today:
=======================================================================
EndState - Terminates the current dialog (popping the stack if we are
inside a subdialog), and returns a logical outcome (to drive transition)
in one of two ways:
* If a view identifier was configured, cause that view to be
rendered and return the logical outcome from the application
action that is invoked (just like a ViewState, but also
terminates the dialog).
* If no view identifier was configured (meaning that the parent
dialog will be responsible for rendering the response to the
current request), simply return the logical outcome that caused
this EndState to be selected.
=======================================================================
Maybe it's just my ignorance; in that case, I'll apologize up front.
However, I assumed that it would have been possible to perceive
(sub)dialogs as black box components. But it appears that I (as the
enclosing dialog) need to understand the inner state transitions of the
subdialog in order to be able to respond to its outcome. ("...simply
return the logical outcome that caused this EndState to be selected.")
I'm not really that interested how the dialog arrived at a certain
EndState; quite frankly, I couldn't care less. The only thing that I
really care about the particular EndState in which we arrived at the end
of the subdialog.
UML 2.0 sub state machines also have a different notion. The only things
defined on the outside of a sub state machine are its potential exit
points. The enclosing state machines can use these exit points to bind
it to the transitions that are relevant in their own domain.
I'm also having a hard time to understand this line "If no view
identifier was configured (meaning that the parent dialog will be
responsible for rendering the response to the current request)..." Does
that imply that dialogs without a view identifier in the EndStates can
only be invoked by other dialogs? It seems that this time the dialog
itself needs to be aware of the way the way that it is going to be used,
right?
Would it be an option to change this into a slightly different approach?
Like, assuming that the enclosing dialog (as long as there is any) will
always be responsible for selecting a view based on some attribute of
the EndState of the subdialog? (And to revert to the view id if there's
nothing on the call stack able to deal with the EndState?)
Thanks,
Wilfred
--
_________________________________________________________________
Wilfred Springer Phone : +31 (0)3 3451 5736
Software Architect Mobile : +31 (0)6 2295 7321
Client Solutions Fax : +31 (0)3 3451 5734
Enterprise Web Services Mail : wilfred.springer@sun.com
Sun Microsystems Netherlands AIM : wilfred springer
http://blogs.sun.com/wilfred/
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact
the sender by reply email and destroy all copies of the original
message.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Dialog Manager
Posted by Craig McClanahan <cr...@apache.org>.
On 9/22/05, Wilfred Springer <Wi...@sun.com> wrote:
>
> All,
>
> Let me start by saying that I *really* like the dialog mechanism in
> shale. Dialogs as first-class citizens have been on my wish list for
> quite a while, and now we have it. Totally cool.
>
> At the same time, I have to say that some of it feels a little bit
> uncomfortable and I mean the exit mechanism in particular.
>
> This is what http://struts.apache.org/shale/ says about it today:
>
> =======================================================================
> EndState - Terminates the current dialog (popping the stack if we are
> inside a subdialog), and returns a logical outcome (to drive transition)
> in one of two ways:
> * If a view identifier was configured, cause that view to be
> rendered and return the logical outcome from the application
> action that is invoked (just like a ViewState, but also
> terminates the dialog).
> * If no view identifier was configured (meaning that the parent
> dialog will be responsible for rendering the response to the
> current request), simply return the logical outcome that caused
> this EndState to be selected.
> =======================================================================
>
> Maybe it's just my ignorance; in that case, I'll apologize up front.
>
> However, I assumed that it would have been possible to perceive
> (sub)dialogs as black box components. But it appears that I (as the
> enclosing dialog) need to understand the inner state transitions of the
> subdialog in order to be able to respond to its outcome. ("...simply
> return the logical outcome that caused this EndState to be selected.")
Yes, that is definitely a bit on the clumsy side.
I'm not really that interested how the dialog arrived at a certain
> EndState; quite frankly, I couldn't care less. The only thing that I
> really care about the particular EndState in which we arrived at the end
> of the subdialog.
>
> UML 2.0 sub state machines also have a different notion. The only things
> defined on the outside of a sub state machine are its potential exit
> points. The enclosing state machines can use these exit points to bind
> it to the transitions that are relevant in their own domain.
Doesn't having to know the exit point suffer from the same problem of having
to know something about the insides of the subdialog (i.e. what possible
exit points there are)?
I'm also having a hard time to understand this line "If no view
> identifier was configured (meaning that the parent dialog will be
> responsible for rendering the response to the current request)..." Does
> that imply that dialogs without a view identifier in the EndStates can
> only be invoked by other dialogs? It seems that this time the dialog
> itself needs to be aware of the way the way that it is going to be used,
> right?
Conceptually, I was trying to cover the cases where the last required
activity inside a subdialog was a View, and the case where the last required
activity was an Action. Both seem to be reasonable use cases.
Would it be an option to change this into a slightly different approach?
> Like, assuming that the enclosing dialog (as long as there is any) will
> always be responsible for selecting a view based on some attribute of
> the EndState of the subdialog? (And to revert to the view id if there's
> nothing on the call stack able to deal with the EndState?)
Perhaps we should add an explicit attribute on an EndState .... "this is the
outcome to return to your parent if there is no viewId".
Regarding the parent *always* being responsible for the next view, I'd like
to think through the use cases some more, to make sure that this would
always be sufficient.
Thanks,
>
> Wilfred
Craig
--
> _________________________________________________________________
> Wilfred Springer Phone : +31 (0)3 3451 5736
> Software Architect Mobile : +31 (0)6 2295 7321
> Client Solutions Fax : +31 (0)3 3451 5734
> Enterprise Web Services Mail : wilfred.springer@sun.com
> Sun Microsystems Netherlands AIM : wilfred springer
> http://blogs.sun.com/wilfred/
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not the intended recipient, please contact
> the sender by reply email and destroy all copies of the original
> message.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: upgrading from struts 1.1 to 1.2.7
Posted by Akshay Pandit <ak...@gmail.com>.
Hi gaurav,
I would suggest reading the change log's of Struts... on struts site...
That would be helpful to you I guess
On 9/22/05, Gaurav Shrivastava <Ga...@lntinfotech.com> wrote:
>
> Hi,
>
> I am new to struts and migrating one of the application on struts
> 1.1 to struts 1.2.7
> please let me know what all things i should take care of while upgrading
> struts.
>
> any hints / suggestions will help me a lot.
>
> Thanks & Regards,
> Gaurav
>
> ______________________________________________________________________
>
--
Warm Regards,
Akshay Kumar Pandit
IBM Global Services India Private Limited,
DLF Silokhara, Sector 30, NH 8,
Gurgaon 122 001, Haryana, India
Desk : DS*-7*-25
Phone +91 124 283 6725 (Direct)
Board +91 124 283 2424 Ext. 6725
Mobile +91 9810236243
Re: upgrading from struts 1.1 to 1.2.7
Posted by Christian Meder <ch...@absolutegiganten.org>.
On Thu, 2005-09-22 at 16:32 +0530, Gaurav Shrivastava wrote:
> Hi,
>
> I am new to struts and migrating one of the application on struts
> 1.1 to struts 1.2.7
> please let me know what all things i should take care of while upgrading
> struts.
>
> any hints / suggestions will help me a lot.
Be sure to checkout this page in the wiki
http://wiki.apache.org/struts/StrutsUpgrade
Christian
--
Christian Meder, email: chris@absolutegiganten.org
The Way-Seeking Mind of a tenzo is actualized
by rolling up your sleeves.
(Eihei Dogen Zenji)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
upgrading from struts 1.1 to 1.2.7
Posted by Gaurav Shrivastava <Ga...@Lntinfotech.com>.
Hi,
I am new to struts and migrating one of the application on struts
1.1 to struts 1.2.7
please let me know what all things i should take care of while upgrading
struts.
any hints / suggestions will help me a lot.
Thanks & Regards,
Gaurav
______________________________________________________________________