Filed under: actionScript, cairngorm, client side, development, flex, server side, tutorial, validation
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/implementorSo 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.
Filed under: actionScript, development, flex, server side, tutorial, validation
recap
So last we left off we had discussed the reference method for passing info back and forth to the relevant view notifying the user about needed data changes. If you need a refresher check part 1. This next way of handling service validation errors is very simple, however it requires a bit more work.
central event dispatcher method
This method requires two additional classes which we will call something like ServiceValidationEventDispatcher & ServiceValidationErrorEvent. I am not too good at naming things off the top of my head so feel free to lay into me on this one. The point is this: We want a globally accessible IEventDispatcher class we can tap into from both the views and the commands. And we want an event that we can attach some data to in order to pass it back. The SVED is pretty straight forward so I won’t create that here. Just know its an IEventDispatcher and I would make it a Singleton-type class. The new event class should probably look kinda like this:
package com.foo.events
{
public class ServiceValidationErrorEvent extends Event
{
static public const SERVICE_VALIDATION_ERRORS:String = "serviceValidationErrors";
public var errors:Array = [];
}
}hooking it up
We are hanging onto the interface from part 1 but we’re gonna modify it for this particular implementation. Instead of the passing the array to the handleValidationErrors, we are gonna pass it a ServiceValidationErrorEvent as the parameter.
Another change we do is instead of passing the view as a value on the Cairngorm event, we will tell the ServiceValidationEventDispatcher instance to register our handleValidationError method for the ServiceValidationErrorEvent:
ServiceValidationEventDispatcher.getInstance().addEventListener(ServiceValidationErrorEvent.SERVICE_VALIDATION_ERRORS, handleValidationError);Now at this point we have a few choices. We need to make sure that we are doing our best to preserve memory and garbage collection. One way is to use a weakReference when adding the event handler. I am not a fan of this because a) we cannot control garbage collection and b) it leaves too many doors open for timing issues.
Another means would be to make sure that we always trigger the handleValidationError method on our view, checking the errors array’s length. For one reason we will be removing the event handler from the SVED. But this means then we always have to trigger it from the SVED within the command regardless of the response’s success. The other way would be to have yet another handler on the view for successful validation so that you can go ahead and remove the handler. This means fattening up our interface. There are so many little things you could do here, but the main purpose is that we are using events to trigger out handlers rather than direct triggering via a reference.
summary
I really don’t dig this implementation because it adds more classes and more crap to remember to do. But here is a pro/con list for this method:
pros:
- better OOP than the ref method
- decouples the view from the command
- leverages the event driven nature of the flash player
cons:
- adds additional weight to your project
- prone to timing issues
- more stuff to remember to do
Ok so part 3 is coming next. It will basically be a blending of the two previous methods. See ya then
