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. Lets think of what not fixing this would imply. Should you really have to hit a "Cancel" button inside the dialog in order for your "my account" link to work properly? What if the user wants to stop checking out and look at their account? Do you stop showing all links and buttons on the screen just because you are now "in a dialog?" If you treat the dialog as a special multi-step view, and not as a modal popup, then the user should be able to click around the webapp just like they could before the developer decided to use a shale dialog. Taking this one step further ... lets assume we're ok with fixing SHALE-276. If the user has effectively canceled the "Checkout" dialog, by clicking on a non dialog related commandLink. What happens when the user clicks on a second dialog, lets say "My Account"? I'm assuming here that both dialogs are launched from the same view. Right now our scheme thinks that you want the "Checkout" dialog because that was what was last stored in the view. But you really want the MyAccount dialog. I'm not sure how we solve this last problem but its definitely a problem. Sean
