On 12/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: craigmcc
Date: Mon Dec 4 16:04:26 2006
New Revision: 482418
URL: http://svn.apache.org/viewvc?view=rev&rev=482418
Log:
Implement the remainder of the functionality needed for event processing in
shale-dialog (SHALE-251):
* A new listener interface (DialogLifecycleListener) and associated
abstract base class. If the application defines an application scoped
(not required, but conventional) managed bean that implements this
interface under a reserved managed bean name (Constants.LIFECYCLE_ATTR),
this listener will be notified when new DialogContextManager instances
are created (placed into session scope) or removed (removed from session
scope either deliberatly or because the session timed out). This gives
the application a hook to add listeners anywhere and everywhere it needs to.
<snip/>
The events I associate with either ends of a "lifecycle" (in the
context of web apps) are init and destroy. Do you think the callback
names onInit and onDestroy would be better (though I see onInstall and
onRemove making sense in the HttpSessionBindingListener sense, but
maybe thats an impl thing)?
* As a convenience, modify the contract for DialogContext.setData() such that,
if the specified "data" object is of a class that implements
DialogContextListener, automatically register it (upon entry) and
deregister it (upon completion of the dialog). This makes it extremely
simple for applications that want to be notified as states change, since
the app will most likely have a "data" object to maintain conversational
state anyway.
<snap/>
Indeed :-)
I did not see anywhere else that shale-dialog-scxml messed with the
data field directly; if there are such places, they will need to have the
listener related logic added there as well.
<snip/>
That should be it, but I'll take a look after dinner.
-Rahul
