Support events from DialogContextManager in addition to DialogContext

• Key: SHALE-351
• Type: New Feature
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Craig McClanahan
• Reporter: Craig McClanahan
• Component/s: Dialog
• Fix Version/s: 1.0.4

Description

The current dialog APIs make it possible to register for fine grained events on a particular DialogContext, but not on events from DialogContextManager. In particular, it is not currently possible to be notified when a new DialogContext instance is created via navigation. Address this by adding eventing to DialogContextManager along the following lines:

* New DialogContextManagerListener interface with onCreate() and onRemove() methods

* New AbstractDialogContextManager that implements the listener registration stuff
  (analogous to AbsractDialogContext for context level event)

* Modify the two DialogContextManager implementations to extend this new base class
  and to call the event firing methods at the right times

* Unit tests for all of the above (of course :-)

* For naming consistency, consider renaming DialogListener to DialogContextListener
  and associated ripple effects. We can minimize transition impacts on current apps
  by leaving a deprecated DialogListener interface that simply extends DialogContextListener
  (and so on).

Comments

[Rahul Akolkar]

Since the DialogListener has never been part of a release, perhaps we can consider renaming it without leaving the package with deprecated classes in its first release itself?

As a purely stylistic comment, AbstractDialogContextManagerListener is about as long of a classname as I personally prefer, but I have no better ideas ATM either, and it seems consistent, so lets just make progress.

I take it this is assigned to you? In any case, I'd be happy to update the dialog-scxml module once the base is in place, if that helps.

[Craig McClanahan]

Regarding renaming DialogListener, I agree with the "just rename it" approach. I had forgotten we haven't actually released this yet.

Regarding AbstractDialogContextManagerListener, I agree with you about the length ... fortunately it only needs to get used twice :-). I'll also go ahead and make the three-line change to SCXMLDialogManager.

I also noticed a couple of places where we haven't followed the JavaBeans *conventional* patterns (not defined in the specs, but seems to be commonly recognized by IDEs) of being able to call getFooListener() and get an array of registered listeners back. There's also a couple of places we need to clean up synchronization, or add some missing ones.

A remaining design issue is a bootstrapping one ... how do you find out when a DesignContextManager gets created and adde to a user's session? (And, likewise, when it goes away.) That will probably require one more sort of listener declaration, probably with a PhaseListener style registration.

[Craig McClanahan]

The bootstrapping concern has been addressed. In addition, the most common use cases for dialog events have been dealt with by automatically registering the "data" object as a DialogContextListener if it implements this interface.