You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by Veit Guna <ve...@gmx.de> on 2007/03/12 22:04:25 UTC
shale dialog handling
Hi.
I'm new to the shale dialog component and I'm evaluating whether to use
it in my webapp. Since documentation is a bit poor, I hope somebody can
clear things up for me.
First thing I encountered was, that a dialog can't be started "twice". I
have a menu where for example a search dialog can be started through a
commandLink action="dialog:foobar". If I press the search link again, a
IllegalStateException occurs. I've read something on the mailing list
about stopping the dialog before starting it again. But that sounds odd
to me. Why doesn't the framework do this for me :)? If I would
stop/start it manually, where would I do it? Since the commandLink
instantly calls the dialog with action="dialog:foobar", I have to add an
additional method to start the dialog programmatically. But for what is
the action="dialog:foobar" then if it breaks if someone calls it twice?
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?
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.
How is this handled with shale? Is there any documentation about this
problems/solutions?
Thanks in advance.
Veit
Re: shale dialog handling
Posted by Veit Guna <Ve...@gmx.de>.
> > 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.
> 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
>
> That does indeed seem like a reasonable thing to provide support for
> ... gotta think about how for a while, though.
Ok, that means there's currently no out-of-the-box shale-dialog function/configuration that can deal with this. So I have to think about it again...
> > 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:
For me it simply means, if the user clicks twice (start dialog), handle it like it's the first time the user starts the dialog. So currently that has to be done programmatically, mh. Would be nice if it could be configured :). In practice, isn't this the default dialog usecase? I think in minor cases the developer wants to stop the user from calling the dialog again. The user could step backwards until he reaches the start point, but calling the dialog again would be easier for the user. Both would lead to an initial state (top+stack strategy).
> > 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
> >From a functionality point of view, the original intent of Shale
Thanks for the detailed answer. I took a look at the current webflow jsf implementation state. It also has some jsf related problems that are open in JIRA...
Veit
--
"Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
Re: shale dialog handling
Posted by Craig McClanahan <cr...@apache.org>.
On 3/13/07, Veit Guna <Ve...@gmx.de> 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" <cr...@apache.org>
> An: user@shale.apache.org
> CC:
> Betreff: Re: shale dialog handling
>
> > On 3/13/07, Veit Guna <Ve...@gmx.de> 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
>
Re: shale dialog handling
Posted by Veit Guna <Ve...@gmx.de>.
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" <cr...@apache.org>
An: user@shale.apache.org
CC:
Betreff: Re: shale dialog handling
> On 3/13/07, Veit Guna <Ve...@gmx.de> 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
Re: shale dialog handling
Posted by Craig McClanahan <cr...@apache.org>.
On 3/13/07, Veit Guna <Ve...@gmx.de> 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
>
Re: shale dialog handling
Posted by Veit Guna <Ve...@gmx.de>.
> 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
Re: shale dialog handling
Posted by Craig McClanahan <cr...@apache.org>.
On 3/12/07, Veit Guna <ve...@gmx.de> wrote:
> Hi.
>
> I'm new to the shale dialog component and I'm evaluating whether to use
> it in my webapp. Since documentation is a bit poor, I hope somebody can
> clear things up for me.
>
> First thing I encountered was, that a dialog can't be started "twice". I
> have a menu where for example a search dialog can be started through a
> commandLink action="dialog:foobar". If I press the search link again, a
> IllegalStateException occurs. I've read something on the mailing list
> about stopping the dialog before starting it again. But that sounds odd
> to me. Why doesn't the framework do this for me :)? If I would
> stop/start it manually, where would I do it? Since the commandLink
> instantly calls the dialog with action="dialog:foobar", I have to add an
> additional method to start the dialog programmatically. But for what is
> the action="dialog:foobar" then if it breaks if someone calls it twice?
>
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.
> 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?
>
> 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.
>
> How is this handled with shale? Is there any documentation about this
> problems/solutions?
>
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.
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
page itself, but you do need to deal with the fact that the standard
JSF navigation rules will not be consulted when the dialog is active.
> Thanks in advance.
> Veit
>
Craig