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
