recap
Last time we discussed two methods for handling service validation errors in a Cairngorm application. The first method was to borrow from some AS2/ARP techniques by passing a reference. The second method was to leverage the event nature of Flex and use a central event dispatcher type approach. Both of these have their advantages and certainly have their disadvantages. This last approach will try to take the best from both worlds and combine them to alleviate some of the problems we encountered.
ServiceValidationErrorManager method
Again you will have to pardon the names here but this gets the point across. There is no doubt what this puppy does. For the sake of simplicity I will continue to call it “the manager”. Ok so the manager is a) a Singleton-type class and b) has at its root a property called currentClient. Here’s a peek:
pacakge com.foo.managers
{
public class ServiceValidationErrorManager
{
public var currentClient:IServiceValidationClient;
static private var _instance:ServiceValidationErrorManager;
static public function getInstance (){}//you get the idea....
}
}
The idea is pretty much the same as the first method in that our views serve as the IServiceValidationClient. When dispatching a Cairngorm event we register the client with the manager class (if applicable). Basically that is achieved by:
ServiceValidationErrorManager.getInstance().currentClient = this; //the view/implementor
So this fixes issues from the other two methods. Firstly it eliminates the need to pass the view to the command. Secondly it doesn’t get us tangled up in all these IEventDispatcher methods.
Now upon a response that has some validation errors, we can simply say:
ServiceValidationErrorManager.getInstance().currentClient.handleValidationErrors();
The other nice thing is that we needn’t really worry about garbage collection because we’re only dealing with one property on one class. It gets overwritten when needed. Now you may be asking why use a separate manager type class. Well you may want to have some logic in there for various things including queuing the views, and other crap I can’t think of right now.
summary
This could easily be adapted to a preexisting singleton model so you can reduce the need for the additional class. You just gotta remember its there. Also, even though you needn’t clear out the property on the manager, it does make good practice. Having a manager class allows you to do just that: manage validation errors appropriately. Of course this might be a grotesque oversimplification of a very serious need, you get the gist of the idea.
pros:
- OOP
- negates the use of IEventDispatcher logic in both view and command
- provides a centralized place to handle more robust registration for error handling
cons:
- adds another class
- still doesn’t address timing issue, unless you implement some queuing mechanism in the manager when setting the current client
- not as elegantly simple as method one
That’s it folks. 3 very ugly solutions to an ugly problem. Chime in and let me know how you do it. Thanks.