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.

This is somewhat new territory for me.  I’ve done enough JavaScript back in the day, but haven’t really touched these new JavaScript frameworks.  Of course the language changed (with the frameworks) and then there’s the obvious presence of HTML5 and CSS3 into the web that’s definitely upped its game.

That said, I pretty much had no idea what I was getting into.  My main expertise now lies in compiled code for enterprise projects (mostly Flex) that has its own automation process.  It was efficient and helpful; it made me happy.  Now I’m thrown back in a world of ‘archaic’ non-compiled language, or so I thought.

First thing’s first, I needed to seek tooling for this language that could automate the process.  In my experience, most JavaScript projects would use Ant to package the project together for deployment.  I’ve grown past Ant and have used Maven for most of my Flex projects for around 2 years now.  It’s a great automation tool that takes a bit of time to set it up, but it vastly improves the process of compiling, testing and deploying.  What I wanted to do is find a Maven plugin that would unit test the code, compress the files, then package it all into a WAR file for easy deployment.  Seemed easy enough.

It wasn’t.

Apparently, most JavaScript developers don’t even know what Maven is, let alone unit testing or a continuous integration engine.  This frustrated me to no end;  how can a developer not know about tools that make the process simpler, more efficient and reduce human error?  Googlin’ didn’t offer much help either; there is very little to no documentation about this process, which led me to write this post.

I found a few maven plugins but most of them were severely lacking in documentation, meaning that I was poking and prodding blindly with the hope that the plugin would output something useful.  This went on for a few days with little progress until I stumbled upon a plugin called Testlol made by Bodil Stokke.  It was well documented and made it easy for me to integrate it into my maven build.  This particular plugin runs unit tests through Rhino (a headless java browser), outputs the results, runs JSLint (a code quality tool) and packages everything in a War file.  Perfect!  I just needed to run Yahoo’s JavaScript compressor through an aptly named plugin before packaging it.

It only took me a few hours to figure it out once I found the Testlol plugin, but I still spent days trying many other undocumented plugins before I arrived to a solution. I couldn’t seem to find an example for a Pom that I could use on my project, as if nobody has ever done it before or at least didn’t blog about it.  I asked questions on forums and several IRC JavaScript channels but they all fell on deaf ears.  On my third day of trying to figure out this problem, It donned to me why nobody knew about Maven or automation: most JavaScript developers are not developers, they’re “scripters”.  After reading some of the IRC logs, it seemed obvious that most do not understand the concept of OOP, design patterns, frameworks or even MVC.  I’m not saying *all* of them are like that. I know many great JavaScript developers like my colleague and friend David Padbury; but the truth of the matter is that real developers in the JavaScript world are few and far in between.

That being said, I turned my frustration into an opportunity to help others.  Here is the Pom I’ve used on this project.  The documentation on each respective plugin are found at the links posted above. Hopefully this will help another developer.

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 

http://maven.apache.org/xsd/maven-4.0.0.xsd">

	<modelVersion>4.0.0</modelVersion>

	<groupId>com.company.coldsteel</groupId>
	<artifactId>client</artifactId>
	<version>1.0-SNAPSHOT</version>
	<packaging>war</packaging>

	<name>Project ColdSteel</name>
	<url></url>

	<!-- Extra plugin repositories other than the usual ones under the maven repo -->
	<pluginRepositories>
		<pluginRepository>
			<name>oss.sonatype.org</name>
			<id>oss.sonatype.org</id>
			<url>http://oss.sonatype.org/content/groups/public</url>
		</pluginRepository>
	</pluginRepositories>

	<!-- the dependencies to get from the server for this to work -->
	<dependencies>
		<dependency>
			<groupId>tv.bodil</groupId>
			<artifactId>maven-testlol-plugin</artifactId>
			<version>1.2.2</version>
		</dependency>
		<dependency>
			<groupId>net.alchim31.maven</groupId>
			<artifactId>yuicompressor-maven-plugin</artifactId>
			<version>1.1</version>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>net.alchim31.maven</groupId>
				<artifactId>yuicompressor-maven-plugin</artifactId>
				<version>1.1</version>
				<executions>
					<execution>
						<id>compress</id>
						<phase>package</phase>
						<goals>
							<goal>compress</goal>
						</goals>
						<configuration>
							<nosuffix>true</nosuffix>
						</configuration>
					</execution>
					<!-- Skip over JSLint, testlol already does it -->
					<execution>
						<id>jslint</id>
						<phase>install</phase>
						<goals>
							<goal>jslint</goal>
						</goals>
						<configuration>
							<skip>true</skip>
						</configuration>
					</execution>
				</executions>
			</plugin>
            <plugin>
                <groupId>tv.bodil</groupId>
                <artifactId>maven-testlol-plugin</artifactId>
                <version>1.2.2</version>
                <executions>
                    <execution>
                        <phase>test</phase>
                        <goals>
                            <goal>test</goal>
                        </goals>
                        <configuration>
                            <!-- path to the javascript folder, more on this later -->
                            <basePath>src/main/webapp/javascript</basePath>
                            <!-- path to the test folder, more on this later -->
                            <testSuite>src/test/javascript/</testSuite>
                            <globalFiles>
                                <!-- Files needed to able to run tests -->
                                <param>src/main/webapp/javascript/jquery/jquery.js</param>
                                <param>src/main/webapp/javascript/someclass.js</param>
                            </globalFiles>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
	</build>
</project>

From here, you simply need to install Maven, use the command line to change directory to the project and run ‘mvn clean install’.  Everything will be then tested, quality controlled, compressed and packaged for you.  However, for this to work you project need to adhere to a specific folder structure for it to work.  Here’s an example of said structure:

This is the usual structure where you separate out the JavaScript part (main/javascript) from the html (main/webapp) and extra assets (main/resources) which the plugin aggregates together when compiling.  The only problem with this is that it makes it very hard to do rapid prototyping since you need to compile it after every change to see it updated in the browser.  To increase the efficiency of development, I instead opt to move the’ javascript’ folder and ‘resources’ folder into the ‘webapp’ folder.  This way I can work directly from the ‘webapp’ directory and the packager doesn’t care.  You can see these changes in the pom above. Here’s what my current directory structure looks like:

One important part of this is the ‘test’ folder;  the plugin automatically runs every file within this folder using JSUnit unit testing library.  The reports are then compiled and outputted to the prompt as well as a detailed xml report created in the target directory.

Your project is now enterprise ready. You can now integrate this within an automation engine like Teamcity or Hudson and make it compile every time a developer enters code and send an email out if there’s a failure. Just be sure to write lots of test to capture some of the possible bugs within the code base and let the system work its magic.

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.

Ever since I started developing Flex, the only real Enterprise level framework out there that was tried and trusted was Cairngorm.  It tries (emphasis on tries) to implement an MVC pattern in your projects so that it’s easier to manage and reuse your code.  However, something I’ve noticed over the years is that Adobe Consulting, the people that made Cairngorm, are not exactly great developers.  This is very apparent with the framework they put out because even though they say that it’s an MVC framework, it is not.  It’s very far from a good MVC pattern, but since it was the only one out there, a lot of developers didn’t have a choice other than creating a new one from scratch.

Fortunately, this has recently changed with a plethora of new frameworks that actually do implement MVC properly.  The two most notable are Swiz and Mate.  Both are really good, however only Mate utilizes Flex to its full potential since most of it can be done with MXML.  It makes it very easy to use and actually quite fun to code with.

In the spirit of supporting and using this fine open source project, I registered another channel on Freenode called #flex-mate.  This would be an open discussion channel about the Mate framework.  If you’re in any way related to the Mate framework, I strongly suggest you come visit the channel and support this amazing project.