shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <>
Subject [jira] Assigned: (SHALE-351) Support events from DialogContextManager in addition to DialogContext
Date Mon, 04 Dec 2006 20:17:57 GMT
     [ ]

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

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

> Support events from DialogContextManager in addition to DialogContext
> ---------------------------------------------------------------------
>                 Key: SHALE-351
>                 URL:
>             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:
For more information on JIRA, see:


View raw message