On 11/15/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> It could also be we should consider this scenario (trying to start a second > dialog when there's an active one) to be an error condition, and throw an > exception or something. What about a custom runtime exception? That could be helpful for my bookmark scenario as well. I could have a filter that caught these exceptions and would simply redirect to the start of the dialog in the book mark case or cancel the old dialog and start the new dialog in the dialog switch case. Or maybe add this to the chain logic?
Hmm ... at least for shale-dialog-basic, the current code definitely has a problem. But it doesn't *look* like it acts the way you describe it. It looks like it will just replace the old DialogContext instance for this view with a new one, but NOT delete the old one from the set of active ones, thus creating a memory leak until the end of the current session. But, it looks like the new dialog would start at the beginning again, instead of picking up where it left off. Are you sure that the new dialog instance is actually getting created? (You can tell by seeing whether the dialog id is the same before and after). That being said, it seems like starting a new dialog when there is an active one is definitely an error condition we should watch for. The logical thing would be to throw IllegalStateException (or some dialog-specific subclass) from the create() methods on DialogContextManager. That way, you'd see the problem immediately if you are programmatically starting a dialog. For starting a dialog via a logical outcome, this exception will percolate out from the navigation handler, but IIRC the JSF layer will swallow it. Need to look at that a little bit further.
Craig Sean
Craig
