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.

This entry was posted in languages, programming, theory and tagged , . Bookmark the permalink.

3 Responses to Flex Frameworks

  1. Russ says:

    I felt compelled to comment on your take of the global event system “problem”. These frameworks aren’t introducing the global event system as a result of being stuck in the stateless web application frame of mind. They’re attempting to avoid some pain caused by the need to get references to the dispatcher in flex’s event system.

    A case that I’ve come across numerous times is when a component needs to listen to an event from another component, but has no reference to said component. Basically they’re trying to avoid lines like this:
    this.parent1.parent2.parent3.application.child1.child2.child3.addEventListener(“poop”, poopHandler);

    This essentially maps out the structure of your application, which leads to headaches should that structure ever change.

    Cairngorm, Model glue flex, and PureMVC have all decided to bypass the flex dispatcher/listener need and devised other means of propagating events that doesn’t require having a reference to the dispatcher. If you want to use the built in flex event system, its probably enough to have a global way to get references to any component you want, but then you’ve introduced a fledgling framework of sorts.

    Hopefully that outlines why the framework designers decided to break out of the flex event system. I don’t pretend to defend the solutions they came up with, I just recognize the motivation. There’s probably a way to build a large flex application using the built in event system, but short of building it as one huge file to avoid the dispatcher/listener problem, I haven’t seen it.

  2. Daniel Roop says:

    @Russ

    Thanks for the comments. Also I thought you didn’t read our blogs ;-). Anyways, I see your point, but I would counter that point with a question. Why do two heavily emended components need to talk to each other? There is a reason why we build abstractions, and I believe it is so we don’t tie peices together like this.

    In your scenario, I would imagine if ever your component (we will call it a) that needed to listen for the “poop” event from component b, then component b should set it’s event as bubble, or component b should dispatch that to it’s parent all the way to the top. Otherwise I believe you will be breaking layers.

    The more I look at flex the more I see layers, I just think it is in a different sense. Presentation -> Business -> Integration still exists but I believe it exists for each component you build. If two component or sections of your application need to communication, then they should do so through the presentation layer. I wish our colleague Mr. LeGros would post his thoughts on Component Based Design in flex, so that I could link to it here ;-).

    So for instance if you had a search section and a shopping cart sections. Each one would be a component, each component would manage it’s own Remote Object/Services and dispatch events it felt were appropriate for other components to be made aware of. I realize this might duplicate work if you ever find some new peice of information that needs to be dispatched, but it also reduces prevents tight coupling between your components, thus making each component more re-usable across different applications.

  3. JosephS says:

    ” 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.”

    Lol. I know what your intent is, but I could not help laughing at this and thinking. “Um…Yeah. It was called ColdFusion 5 or prior.”

    And as for a RemoteObject framework your spot on. I got to this site because I am dealing with that issue right now. Comming from a ColdFusion background I where we made heavy use of Flash Remoting and Coldfusion Flash forms I have embarked on my quest for Flex Knowledge. I have 5 different ways of using RemoteObjects up on screen now that I found with a single Google search and none of them are exactly the same. I guess I will just have to pick one and run with it.
    if(1=2){ doSepuku(); }

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>