[dialog2] Sharing data between dialog instances

[Craig McClanahan <cr...@apache.org>]

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