On 3/13/07, Veit Guna <[EMAIL PROTECTED]> wrote:
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.
Presumably, what we'd want to have happen in the menu case is to
terminate the currently active dialog instance (if there is one).
Then, the menu option can start its own new active dialog if it wants
(by returning an outcome starting with "dialog:" on it). Right now,
there's nothing in the dialog APIs that directly helps in this
scenario.
Right now, short of adding all the appropriate transitions to every
view state (yuck), the only mechanism I can think of that might deal
with this is to define your own JSF "default action listener" -- the
gadget that actually invokes the action method in your backing bean
and then does the appropriate navigation. One could contemplate
writing such a handler that would notice that this transition is
external to the dialog (somehow TBD), and terminated the current
dialog instance programmatically.
That does indeed seem like a reasonable thing to provide support for
... gotta think about how for a while, though.
And what about start-over a dialog when the user clicks a start-dialog-link
again? Is the programmatic approach the only one?
What does "start over again" really mean? I can think of two
different ways to implement this:
* Programmatically terminate and create a new dialog context instance.
* Execute an action that clears any state information that has been
collected, and transitions back to the start state.
In the latter case, you're just reusing the same instance, but
starting over on the data collection. That seems easier to deal with
than starting a new instance programmatically.
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?
From a conceptual level, Shale's dialog manager leverages the fact
that Shale requires JSF, so it leverages existing JSF features for
navigation, and things like using a method binding expression to point
at the logic you want to execute in an action state, which will be
familiar to a developer already using JSF. Spring Web Flow, because
it is more general purpose, has to provide its own mechanisms to
manage navigation and function invocation no matter what web framework
you are using it with (of course, it will leverage things that are
familiar to Spring-using developers :-).
From a functionality point of view, the original intent of Shale
dialogs was to provide a much simpler set of functionality that
covered the 80% use cases -- for advanced developers who needed more
sophisticated transition management, you could still use Spring Web
Flow if you wanted. Since that time (starting with release 1.0.4) we
abstracted out the basic dialog manager APIs so we could support
multiple implementations, and a second implementation (based on State
Chart XML and the Commons SCXML engine) was also provided. In theory,
it would be possible to write an adapter that let you deal with Shale
dialog manager APIs in your app, but use Spring web flow (or any other
"conversation" style engine) under the covers. That approach might be
useful if you're transitioning from one approach to another -- or you
need sophisticated capabilities only for a portion of your app.
Veit
Craig
-------- Original-Nachricht --------
Datum: Tue, 13 Mar 2007 09:30:42 -0700
Von: "Craig McClanahan" <[EMAIL PROTECTED]>
An: user@shale.apache.org
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
