> 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?
> > 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.
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?
> > 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.
Veit
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out
