Re: shale dialog handling

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" <craigmcc@xxxxxxxxxx>
An: user@xxxxxxxxxxxxxxxx
CC: 
Betreff: Re: shale dialog handling

> On 3/13/07, Veit Guna <Veit.Guna@xxxxxx> 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