I've been doing a bit more experimenting a bit more with popups (and added a menu option to shale-test-dialog2-legacy to create one). As I expected, the popup window does indeed create its own dialog instance if it happens to use the same dialog name as the main window (same as with frames, or with windows manually created by the user). None of the various dialog instances interfere with each other.
That's all well and good if the dialogs are totally independent ... but what if they are not? I suspect this might be part of the popup use case conundrum that Sean was describing ... if, for example, the point of your popup window is to go do a search or something, and then feed it back into the main window's dialog when its done, the popup dialog needs to find the main window dialog it's associated with. Further, if I have two main window dialogs, each with their own popups, then each popup should be associated with a correct main window dialog that they came from. Here's some initial thoughts on general approaches to the problem we might consider: (1) Let the application do its own data orchestration - That's really punting on what should be the framework responsibility. (2) Use a subdialog somehow. - Logic in the subdialog could walk up the stack of state information to put the updated information back. This would likely need extra API support - Only works well if the underlying dialog is modal ... and that's actually pretty hard to do on the web. (3) Separate shared data storage area - Conceptually, some HTTP session scoped variable that stores "global" data from all active dialog instances - Problematic for use cases where there is more than one instance of the same dialog active at once (4) Availability of formal "parent" relationship between dialog instances. - Could allow a popup dialog instance to be specifically tied to the main window dialog instance that it was created from - Should be represented as a property on DialogContext to make navigation to the parent's data storage (via EL) very easy. - Probabably works only for programmetic initiation? I'm thinking option (4) might address these sorts of cases pretty elegantly, and require only minimal API changes to what we've already got in dialog2. What do you think? Craig
