Fixing multiple parsley result handlers being called [Update]

This passed week I was testing my application and noticed some odd behavior. After some debugging, I noticed that two command result handlers were being called, when in fact only one of them should be. The application was built using the Parsley framework, so to quickly explain the problem and solution, here is what was happening:
  1. Application was dispatching the MyEvent1 event
  2. The MyCommand1 was being executed and the MyCommand1 result handler was being called
  3. Then the problem, the MyCommand2 result handler was being called.
So why was the MyCommand2 result handler being called? Because Parsley didn't know any better based on how I coded both handlers. Here is how both handlers were coded:

public function onResult( event:MyEvent1 ):void

public function onResult( event:MyEvent2 ):void

In both cases, the remote java call returns void, so I declared only one parameter for each function, the event that dispatches the command class. Since I didn't specify the event class name (the type as Parsley calls it) in the CommandResult metadata tag, Parsley will use the 2nd parameter to determine the type. Oh, but I don't have a second parameter! Hence the problem, so Parsley just ended up calling both handlers. So there are two ways to solve this problem...

1) Add another parameter to the handler function of type Object that will not be used, like so:

public function onResult( obj:Object, event:MyEvent1 ):void

public function onResult( obj:Object, event:MyEvent2 ):void

2) Declare the event type in the metadata tag, like so:

public function onResult( event:MyEvent1 ):void

public function onResult( event:MyEvent2 ):void

I ended up using solution #1 and then I only had the one result handler being called, which is what I wanted.

UPDATE: Actually good catch by Devin, if you just use the [CommandComplete] metadata tag, then your handler method only requires one parameter, the associated event object. Totally missed this one while reading the documentation.


Devin said...

If the remote service doesn't return a result (null), then you shouldn't use [CommandResult], rather [CommandComplete]. Using CommandComplete, the first argument determines the message type.

Dimitrios "Jimmy" Gianninas said...

Thanks for the feedback Devin, I've updated my post.