Flex Frameworks

Recently there has been a lot of discussion at my office, and online about whether or not a framework is necessary in Flex. Before revealing my opinion I wanted to go over a few reasons why I believe frameworks are used.

I went to Wikipedia and looked for a list of common features in web application frameworks. I choose web frameworks because I believe most Flex developers are coming from a web background. I found a comparison chart of the most common application frameworks, so I based my list off of their chart.

• Ajax Help
• i18n
• ORM
• Testing
• Database Migration/Versioning
• Security
• Template System
• Caching
• Validation (Model/Form)

I felt the need to add a few points that were not listed on their comparison

• Common Application Structure
• Common Request Flow

Now to begin this discussion let’s talk about the items that don’t apply to flex.

Ajax Help

I don’t think I need to say much here. Flex itself is a RIA Framework. More importantly Flex is Flash, and Flash was the original Ajax.

i18n

Fortunately the Flex engineers in their infinite wisdom realized that more and more applications are needed to i18n. I would assume this knowledge came from the fact that most of Adobe’s clients are government organizations, and I would imagine they need to internationalize a lot. Lucky for us we don’t need to solve this problem, we just need to figure out where to store all the properties.

ORM

At the end of the day Flex was designed for building user interfaces, just like HTML and JavaScript. How many HTML ORM frameworks exists? I have heard rumor of a mysterious technology that allows you to connect to a database via JavaScript, but I have yet to confirm the existence of said technology. So I think we can all agree that ORM is a problem that the backend webservice, or remote object will have to address, not Flex, or it’s framework.

Database Migration and Versioning

See previous point

Security

I believe this is the first of a few places where the problem is different in Flex than in Web based Applications. In this case I believe it is almost a non-issue since Flex is stateful, you don’t have the added complexity of maintaining a users session/credentials, in a stateless application. I do believe that there are security issues with Flex but none that warrant a full blown framework handling them.

Template System

First let us define a template system. A template system is not where the view files go, it is what the view files are written in. In the case of Fusebox, or Model Glue, you use a mixture of HTML and CFML. In Java you can choose from Velocity or JSP as your template language of choice. In Flex you have MXML, that is it. In the future some one might come up with a different templating system, but I believe Adobe/Macromedia engineers have developed an extremely powerful templating language, that works very will with ActionScript.

Caching

In web frameworks this traditionally has to do with saving the rendered HTML from the dynamic ColdFusion or PHP to improve performance. This cuts down on processing time, and increases the possible requests per second. Since flex is a compiled artifact, that is delivered all or nothing, there isn’t much caching can help you here.

Validation

Flex has a validation framework. Although I have gone back and forth as to how heavily it should be used, I think it solves the problem domain in the UI. Unfortunately it is very difficult to plug it into some backend validation framework, so if any work is to be done, it would be creating this bridge.

Common Request Flow

This one is complicated, I think in the context of how web developers currently think about this problem, it doesn’t need to be solved. At the very least it doesn’t need to be solved the same way it is solved in web applications. Flex is a stateful application and should be treated as such. Typically an event/message system is used to manage stateful applications. That is why I was so excited about Model Glue: Flex. I never cared much for Model Glue in ColdFusion because I thought the whole event system was awkward, but in Flex it made perfect sense.

After all that we are left with two points that web developers currently use frameworks for that Flex applications need a framework to address.

Testing

Currently there is FlexUnit and ASUnit. Both need some work I think FlexUnit is in the lead, but it is a start

Common Application Structure

I think this is the main piece that needs to be addresses with any framework that is developed. I have seen numerous ways of organizing Flex code, and I am not particularly fond of any of them. But for consultants and corporate types alike, I think defining a common application structure would be beneficial for code readability.

So there is my synopsis… now for my opinion. I do believe that Flex could use a framework. I will admit when I started this post I was not of that opinion. I believe there are a few points that Flex does not spell out for you and defining some additional constraints might help. So here is what I would like to see in the perfect Flex Framework:

Testing

As I said above, there are already testing libraries out there. I would like to see these incorporated into your application (e.g. rails, grails) to encourage the practice.

Common Application Structure

I think as the different pieces are established, this part will naturally develop, but I think it is important to note, because it is the primary job of any good framework, to decided where the different components of the application live.

Remote Requests

I think a common way to make Remote requests would be nice. Most frameworks accomplish this using the command pattern. I would like to see something more like a callback function the way prototype handles remote requests in JavaScript.

new Ajax.request( 'http://danielroop.com/ajax_url', {
   onSuccess : function(transport) {
      alert("Yeah It Worked");
   }
});

The prototype syntax is nice, but being a fan of Ruby I would much prefer something like this:

Flex::RemoteObject.doSomething('parameter') do |result|
  case result
  when Flex::RemoteObject::Success
    puts 'yeah I worked'
  when Flex::RemoteObject::Failure
    puts 'boo I didn't work'
  end
end

Unfortunately ActionScript doesn’t have the notion of blocks, or closures, so I will have to settle with something along the lines of how prototype approaches the problem.

No Global Event System

I wanted to point this out, because I feel this is where the existing frameworks are screwing up. I believe Flex has a very robust, well thought out event system, and I don’t believe it needs to be re-engineered. If there was one point of failure I could point to with the existing frameworks, I believe this is it. This is the point at which they try to turn a stateful application, into a web application.

So there it is. Flex has given us many of the tools that frameworks are traditionally used for, but that is not to say that a Framework is not needed. We just need the framework to satisfy different needs.