* Once you are inside a dialog, the dialog should be the *only* thing that manages navigation. There should be *no such thing* as "outcomes not managed by this dialog" -- any other approach leads to totally non-deterministic behavior that quickly becomes impossible to debug. Based on this, delegating to the wrapped navigation handler (while inside a dialog) seems to me like an exceedingly BAD idea.
What happens if the dialog is a popup and the user closes it? We now have an ongoing dialog associated with the view id. I don't think you'd want the navigation on the underlying page to stop working just because the user aborted the dialog.
* If the advance() method returns null, that should mean the same thing that an action method returning null means -- redisplay the current view. Otherwise, you are going to destroy the ability of a view developer to not worry about whether the view being maintained is used within or outside a dialog (or both). Note that this is going to happen to us by default, if any validation errors occur, so the framework MUST respect this approach.
Null outcomes *still* behave this way. When there is a null view id from the advance method the DialogNavigationHandler will pass the original outcome (null) to the wrapped NavigationHandler which will perform as expected.
Barring further analysis tomorrow, I'm at the moment -1 on this change.
I'm interested in hearing how you would solve my usecase then. I have more usecases if the one above does not convince you.
Craig
Sean
