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 : [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]
