> > 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
