On 9/22/05, Wilfred Springer <[EMAIL PROTECTED]> 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 : [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
