On 10/3/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
Got thinking about SHALE-268 [1], that lead to a couple of things: a) It will need add/removeListener methods on the DialogContext. Would the preference be to provide the basic listeners book-keeping bits in an abstract base class or duplicate them in basic/scxml?
The most common pattern I've seen is to define the listener as an interface, then define an abstract base class with do-nothing handlers for all the event methods. That way, you can just subclass and override the event handler methods you care about. All of this would seem to fit into the core dialog package, since it shouldn't be specific to the implementation you choose. b) What is 'x' when we say 'Entered state x'? IOW, if the
DialogListener is to define a method with the following signature: (public) void onEntry(Object state) what should the type of 'state' be, other than Object, in the presence of varying underlying state machine implementations?
Hmm ... we might want to presume as little as possible about the underlying engine. The minimal common characteristic would be that states have some sort of string identifier, and they are all unique, so maybe that's the best thing to pass in. Thanks,
-Rahul [1] https://issues.apache.org/struts/browse/SHALE-268
Craig
