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.

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.

It integrates completely with Eclipse (and Flash Builder) and has this neat feature called CodeSync that makes sure your model and code is always persisted between each other.  In other words, everything works together in an integrated workflow to save you time.

I’ll have to dig deeper, try this out on projects and do a complete review.  In the meantime, please support this initiative by registering and posting on the forum.

When I’m designing a system, I always try to use proper Flex practices. Practices like using MVC to separate components and business logic, making components truly encapsulated and reusable, etc. The problem that I find with Parsley is that it only allows you to use Injection based views for its MVC architecture; the View knows something, either a Presenter or a Model, and it’s always injected in by the Context.  The problem is, if you have several projects that need the same components but different frameworks, you can’t freely interchange those components between projects since the view is tightly intertwined with the Parsley injection.

A way to solve this by using the Mediator pattern (The View knows nothing, but the Mediator knows about the View) because it makes your view extremely portable between projects and forces the developers to use better practices since the only way to communicate with the Mediator is through events.

Luckily, Parsley has several extension points which you can insert custom classes to change or add functionality.  This gave me an opportunity to create my own parsley tag aptly named ‘Mediator’.  What this allowed me to do is to create a Mediator class that is controlled by Parsley and when the view is created; an event would get dispatched from the View and Parsley would then create a Mediator class and inject the view into it.  This way, the view never knows anything about the framework which leaves the components to be freely interchangeable between projects.

WARNING: The following code only works with Parsley 2.3 and higher.  I made it this way because some major changes have been made to the extension points in 2.3.

You can download the sample application I made and look at the files. All you really need is the Mediator library swc and put it in your project.  Then you need to specify that you Parsley context will use this Mediator extension by doing the following.

<!-- Initialize Parsley like you would normally -->
<spicefactory:ContextBuilder config="{Config}">
	<!-- Except add the mediator configuration within it -->
	<!-- Alternatively, you can use Mediator.initialize(); instead of the mxml tag -->
	<mediator:Mediator />
</spicefactory:ContextBuilder>

And that’s it. By including the Mediator class within your Context, Parsley knows how to change the extension point for it to work.

UPDATE: Instead of giving you the raw files, I’ve packaged them in an easy to use library.  You can now find the source for the library here.

UPDATE 2: I’ve updated the files for the latest 2.3M3 changes in Parsley.

UPDATE 3: Parsley 2.3 came out recently and I’m happy to say that my Mediator still works.

UPDATE 4: Parsley 2.4 is out and I’ve updated the mediator and added it to GitHub.