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!

I have some insider information saying that the opening day party will be all 60′s; like a geeky version Mad Men except with less debauchery. There’s also some roller-skating and cotton candy involved. Nuts right?

If you’re in the industry, you do not want to miss out on this event. Buy your tickets now if you haven’t done so already. And while you’re there, stop by my presentation for support.

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.