[ http://issues.apache.org/struts/browse/SHALE-351?page=all ]
Craig McClanahan reassigned SHALE-351:
--------------------------------------
Assignee: 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.
> Support events from DialogContextManager in addition to DialogContext
> ---------------------------------------------------------------------
>
> Key: SHALE-351
> URL: http://issues.apache.org/struts/browse/SHALE-351
> Project: Shale
> Issue Type: New Feature
> Components: Dialog
> Reporter: Craig McClanahan
> Assigned To: Craig McClanahan
>
> 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).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
