On 3/12/07, Veit Guna <[EMAIL PROTECTED]> 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
