Let’s give a quick example of a simple problem: You need to find the index of a string within a 2D array and do something with that index.  Here’s how I would do it normally:

private function findIndex(text:String):void
{
	var row:Array;
	var index:Point;
	for(var y:uint = 0, ylen:uint = array.length; y<ylen; y++)
	{
		row = array[y];
		for(var x:uint = 0, xlen:uint = row.length; x<xlen; x++)
		{
			if(row[x] == text)
			{
				index = new Point(x,y);
				break;
			}
		}
		if(index)
		{
			break;
		}
	}
	// Do something with index
}

You’ll notice that within the example, the second I find the index, I break out of the loops to reduce the run time of the function. The external loop always looks to see if ‘index’ is not null and breaks out if it is. I’ve never liked this approach because it adds more code than needed and sometimes its not as easy as just checking if a variable is not null. You could always use ‘return’ if your function is done with its purpose, but that’s not always possible.

The alternative to this is using label statements. What you can do is simply ‘label’ your loops and then when you want to break, you can specify which loop that needs to be broken. Take our current example and let’s add label statements in it:

private function findIndex(text:String):void
{
	var row:Array;
	var index:Point;
	outer:for(var y:uint = 0, ylen:uint = array.length; y<ylen; y++)
	{
		row = array[y];
		for(var x:uint = 0, xlen:uint = row.length; x<xlen; x++)
		{
			if(row[x] == text)
			{
				index = new Point(x,y);
				break outer;
			}
		}
	}
	// Do something with index
}

That is much better and cleaner. I’ve seen this done before in Java, but I have never encountered or read about it for Actionscript. This method can also be used with the ‘continue’ operator so that it skips the rest of the code to the next iteration or with block statements like so:

doSomething: {
	var x:uint = index.x;
	if(x > 100)
	{
		break doSomething;
	}
	trace(x);
}

I don’t think I would ever use it with block statements since these could be simply replaced with ‘if’ statements, but knowing about it can be beneficial. I know I will be using label statements in nested loops from now on.

I will say this right away, I’m biased towards Parsley and have advocated its use for over a year and a half now.  It has time and time again proven itself a reliable, robust and rapid framework for application development.  Its track record is quite impressive;  It was used to build some of the world’s largest Flex applications.  Jens Halm, the creator of Parsley, has done a wonderful job at making his framework extensible, fast and optimized for both Flash and Flex.  Robotlegs is also a good framework, don’t get me wrong, it just doesn’t capture me as much and it’s not optimized for Flex (pure Actionscript), but  in the end it comes down to your development preference.

Now to ask the question, which pattern we use for our project? Presenter or Mediator?  Parsley is built around the Presenter pattern while RobotLegs uses Mediator.  Simply speaking, the difference between the two is fairly minimal, but can affect your project quite a bit.  Here’s a quick diagram on how they work:

If you remember your UML class diagrams, you would see that a Mediator can only have one View, while the View can have many Mediators.  In this case, the Mediator is the ‘man-in-the-middle’ since nobody else knows about it; its sole purpose is to listen to the View and give it data.  The View communicates with the Mediator through events to which the Mediator acts upon.  One thing I like about this pattern is that it forces developers to use a proper “data in, events out” methodology and separates the concerns of the business from the View.  This also creates decoupled components since there’s no hard dependency in the View; it could still fully function if it is moved into another project.

For the Presenter, things are a bit different since the View knows about it.  The Presenter is there to just present data which is easily binded within the View, but this is problematic since it’s coupling your View to that Presenter and even the model (data).  However, you don’t need to use events within the View to communicate to your Presenter since you can access its public functions directly.  It’s easier to use this method because it limits the code needed to communicate between the View and the Presenter, but it’s coupling your View.

In the diagram, you might have noticed that with a Mediator pattern you can have a View with several Mediators and even reuse the Mediators on other Views.  This makes the Mediator more of a View based pattern.  The Presenter however doesn’t care and a View can have multiple Presenters which can (and should) be reused across multiple Views to display the data they need.  This makes the Presenter more of a data based pattern since it’s job is to give access to data and manage it.

There you have it.  One thing to remember is that patterns are meant to help you develop, not make it harder.   Since I love Parsley so much and had a need for a Mediator pattern for a project (needed to decouple the component) and Parsley only provides a Presenter pattern, I extended the framework to include a Mediator tag. It’s completely open source and now on GitHub.  Enjoy.

Videos for both presentations are available after the break.

In a way, this project (once it gets started in full force) will be one step ahead of Adobe because of the sheer number of developer resources out there on the web.  Definitely something to keep an eye on, so please sign up and contribute!

As usual, we’ve recorded the workshop on UStream.  You can follow along using the pre-made workshop files or you can skip right to the end and get the completed workshop files.  I hope that this helps anyone out there trying to learn Parsley for their next project.

I’d also like to thank Lab49 for their continued sponsorship of the New York Flex Meetup and events such as these.  As well as Adobe for providing 2 Flash Builder 4 Premium licenses and Shashank Tawari for giving 3 AdvancED Flex 4 books to give away at the event.