>From: "David Geary" <[EMAIL PROTECTED]> > > 2006/9/5, Sean Schofield : > > > > We might want to revisit the one dialog per JSF view assumption. I'm > > playing with the new stuff in shale-petstore and I have run into some > > unexpected behavior. I have a commandLink that kicks off a "checkout" > > dialog. This command link is located in a "menu" bar that is > > displayed on every page using a facelets layout scheme (for those not > > familiar with facelets, the reusable layouts are similar to Tiles.) > > > > Lets suppose there are a few more "menu" options, such as logout, my > > account, etc. I've already made the argument that you should be able > > to "cancel" the dialog by clicking som other command link in the menu > > that has nothing to do with the dialog outcomes (SHALE-276). While > > this might be a PITA to support, its pretty common in a webapp to want > > to click on something else on the screen other then the previous, next > > buttons of your dialog. IMO, the expected behavior would be that the > > dialog stops and the new view is loaded. > > > One way or another, we've got to support non-dialog outcomes during the > course of a dialog. Halting the dialog seems to make sense, but of course, > there will be users that link out of a dialog and then hit the back button > expecting to be back in the dialog. >
I've not spent much time with the dialogs so I might not have the full picture.... The DialogContext is stored by the DialogManager as a session scoped managed bean. The context will always represent the last state of the dialog. If we jumped into an active dialog, the context needs to be restored to the state before the process flow was hijacked. The restored view will have the name of the active dialog (not sure what would happen if you used the same view in multiple concurrent dialogs). What if the DialogContext was stored in the view state like the generated dialog id? The DialogManager could get the state from the restored view. This would be like a checkpoint since the view is serialized by the state manager. I doubt that we would want to make the view manage the checkpoint since that stuff would be serialized to the client when client state saving was turned on. However, what if we store the current index of the "positions" list managed by the dialog manager as the current view root's attribute (like the generated id)? When the view is restored, the context "positions" index would be restored. The data captured in the "references" list is indexed by the current position too. Gary > > david > > > Sean > >
