On 9/5/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> * 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.
With the new implementation, the popup will run its own dialog instance, right? That means that whatever happens there will have no effect on the flow of the main page.
* 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.
Good.
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.
I think the new implementation deals with this use case ... if so, let's review the others as well to make sure it works as needed.
Craig Sean
Craig
