Ok, I see that after a dialog has ended, there's no way to get to it again, using the browser back-button. Clear, that the data object is also lost.
So, lets "forget" about the back-button problem, for now. But what about the usecase of using other links like a menu? I don't want to put every outcome on the page to the dialog configuration. And what about start-over a dialog when the user clicks a start-dialog-link again? Is the programmatic approach the only one? What are the best practices with shale-dialog to handle such things? BTW: a bit off-topic, but what are the major differences between shale-dialog and spring webflow? Veit -------- Original-Nachricht -------- Datum: Tue, 13 Mar 2007 09:30:42 -0700 Von: "Craig McClanahan" <[EMAIL PROTECTED]> An: [email protected] CC: Betreff: Re: shale dialog handling > On 3/13/07, Veit Guna <[EMAIL PROTECTED]> wrote: > > > > > The current design assumption is that you can only have one active > > > dialog per window (or frame), and that you want to control the > > > lifetime. > > > > Hm. Is the lifetime of the dialog not implicitly configured through the > xml? There's a start point and an end point. That seems sufficient to me to > specify the lifetime. Since there can be only one active dialog. Although > it could happen that the user reaches the end page - navigates further and > then navigates back with the browser buttons to the dialog. What happens > then? In what situation do I want to programmatically control a _simple_ > dialog? Couldn't that be configured instead? > > Because all evidence that the dialog was there is totally gone, the > dialog will not be automatically reinstated when the back arrow is > pressed. It is therefore likely that any references your pages have > to dialog instance specific state information will fail. > > You're going to find that nearly every "conversation" or "dialog" type > framework is going to have some level of problems with back buttons. > If you can't convince your users that they are operating a web > *application* and not a web *site*, you're likely to have navigation > issues. > > > > > > > > > What comes to my mind is, why doesn't the framework automatically > stops > > > > the running dialog and starts it over? What is the best practice > with > > > > shale to implement this usecase? > > > > > > I suppose it would be possible to implement such a thing. What's not > > > clear is why you would want to do it. Could you help me understand > > > your use case a bit? > > > > Sure. Think of a webpage, that has a menu on the left. There're entries > like "Search", "User Profile", "Register" and so on. The user can access > the menu all the time during navigation in the webapp. Now he clicks on > "Search" and the dialog starts. He clicks some steps forward in the dialog and > decides (in the middle of the dialog) to "Register". IllegalStateException > occurs. Also, when he presses "Search" to start the dialog again, this won't > be possible. Since he starts the dialog again, why not stop the active > dialog and start a new one automatically? I could think of a configurable > dialog attribute in the xml like "autostartover=true" or something. > > As above, the dialog manager doesn't deal with back buttons crossing a > dialog lifetime boundary at all. That's your responsibility if you > want to do it. Among the problems to consider -- how do you restore > the state data that was previously there? The dialog manager has no > clue what kind of thing you stored in the "data" property. Only the > app can figure that out. Let alone figuring out what state you should > be returned to ... > > > > > Hm, as I'm writing this, perhaps I misunderstand the dialog component? > In my point of view, shale should help me to implement pageflows. > Independent of whether the flow is used in a popupwindow (dialog, no "menu") > or > included in a normal navigation case ("main" browser window, with menus etc.). > Do I understand it correctly? > > You do understand correctly what the dialog component is for. What > you're missing is that it doesn't deal with the "back arrow backing > into a previously completed dialog" use case, and I don't see any > general purpose way that this feature could be provided. > > > > > > > > > Another thing is, clicking other links in the menu when a dialog is > > > > active. Same here: IllegalStateException. A user doesn't care about > > > > program-friendly navigation. A user want's to navigate everywhere he > > > > likes to. > > > For dealing with the back and forward buttons, check out the context > > > init parameter "org.apache.shale.dialog.basic.STRATEGY" if you are > > > using the basic implementation. You can control whether and how state > > > information is synchronized as the user moves forwards or backwards > > > through the dialog. > > > > Yes I know. This is very useful because with top or stack the dialog > data will automatically be set to a consistent (to the current dialog page) > state. > > > > > > > For dealing with navigation from inside the dialog to somewhere > > > outside, the thing to remember is that the dialog manager takes over > > > normal navigation processing when a dialog is active. Therefore, it > > > is up to you to provide transitions for *all* possible outcomes that > > > might be returned from the current page. You don't have to change the > > > > That might be :). But in which real life webapp there is ONLY a dialog > active and no menus, etc.? If we talk only about modal popup windows, that > might be true, but in all other cases the dialog is embedded in a bunch of > other links around. I really don't want to put ALL the links/outcomes around > the dialog (menu etc.) in the dialog definition :)! > > > > So, If the shale dialog component is only designed for modal popups, all > makes sense and you can forget everything I wrote above. > > It's not just modal popups ... it's also for users who use the > navigation controls provided by the application, and not the ones > provided by the browser :-). > > > > > Veit > > Craig > > > > > -- > > "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... > > Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out > > -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
