Blog by Jamie Scanlon

Most Flex / Flash developers I know are using some flavor of MVC to build their applications. It’s greatest strengths are scalability, and rapid development in team environments. But when I came to MVC I had hoped I would also find that the code I had written for one project would be more reusable in projects down the line. And although MVC Frameworks take a big step in this direction, there are still a lot of gotchas that can make it difficult to dig out a class or two from a project you worked on a few months ago and use it in your current project.

Widetized development is a methodology and a thought process that can be applied on top of what ever frameworks or conventions you have adopted already. It doesn’t limit your applications to be used only as widgets.

I have a bad track record for predicting what pieces of code are going to be useful in the future. Most of the classes I build to be reused never are, and the classes I write as specialty one-offs end up being used over and over again. Widgetized development allows you to take a piece of code that was never intended to be used outside of the application is was written for and use it anywhere without rewriting it.

Here are some key principals that you can start using today that will make it much easier to take whatever you are working on right now and use it for something completely different a month from now.

Standardize the Data Model:

I have gotten up on this soapbox many times in the past, but your Models and VO’s are usually the the biggest hurdle. Most likely your current project has a data structure that is very specific to it’s own needs. If you have taken my past advice, you at least have a flat data structure that is not necessarily modeled to look anything like the source it came from but rather it is modeled to make it as easy as possible for your app to get the info it needs. You may even have gone as far as to implement my suggested list of basic methods every data model should have: addItem(), addItemAt(), getItemAt() ,getItemIndex(), removeAll(), removeItem(), removeItemAt(), sortOn(), and toArray().

But how much easier would it be if your data model was a standard library class that you decide to use for every project. Deciding to treat data models with the same level of standardization as the rest of the application will end of saving you a lot of work if that app, or a piece of it, has to fit into another application. If the data model is universal, you will be able to take a piece of your app to another and have it work directly with the data in the data rather than working through a data translation layer.

Outsource the Delegates:

The data model is the lowest level a widgetized application should be concerned with. Dealing with services and delegates should be compartmentalized as this is the one part of any application will not be reusable. The operations behind querying servers, gathering data, and translating the results into data models is very specific. If you build your app such that it does not depend explicitly on any services, service locators, or delegates, it will be easier to take the app ( minus the service interactions ) and stick it in to a new app that will no doubt have it’s own service handling and data gathering classes.

If you are using a Command-based Controller that is typical of MVC frameworks, consider having you commands call their Delegates through an Interface and passing in the actual Delegate class in through the event that triggered the Command.

Alternatively you can limit your commands to strictly setting state variables on your model. If your application is simple enough, having your wigetized command set State.loading = true; could be enough to signal your main application to load in the data in whatever way it knows how. This approach has it’s drawbacks when your application becomes complex and you need some granularity in the way your data gets loaded. Soon you will be stuck with a state object that has 20 different state flags describing 20 different load processes.

Whatever way you accomplish this, your widetized app should have a way of signaling when it needs data and responding when it gets data. And you should figure out a way to do so in a standard way so you can plug it into any future application.

Avoid Frameworks that make excessive use of the Singleton… I’m talking to you Caringorm:

Not that I have anything against one of the most common frameworks in our community, but I have never been comfortable with the number of Singleton classes this framework ( and most frameworks ) uses. The purpose of using a Singleton is to make sure that there can be one and only one of that particular class. Many of the more popular frameworks instead use the Singleton as a way of having a global level class. This can backfire on you if you are not careful.

Take for example a recent problem I encountered when I had a Caringorm based video player and I wanted to use in in an application where there needed to be multiple instances of the video player on stage at once, each with it’s own video source and it’s own controls. Since I was using Cairngorm which uses a Singleton for it’s FrontController, ModelLocator, and CairngormEventDispatcher classes, all of a sudden all of the instances of the video player were forced to share a Data Model and State ( through references through the ModelLocator ) and all responded to each others events ( through the CaringormEventDispatcher and FrontController classes ). It turned out that clicking play for one video player made them all start playing… not good.

Singletons act on a global domain level. That’s why it’s important to make sure that the use of Singleton classes truly passes the ‘there can be one and only one’ test ( a test that obviously the Cairngorm Singleton classes do not pass). Widgetized development is all about the possibility of having multiple instances. Be very weary about using any framework that makes liberal use of Singletons, and if you must, consider extending or modifying them so that you be sure you do not have collisions when your widgetized app is instantiated multiple times.

A lot what it takes to cope as a Flash / Flex developer nowadays is understanding the Flash Security Model. With all of the embedded, widgetized, web service based applications Flash is being used for, a thorough understanding of Flash Security will save you hours of debugging time and make you seem like a genius to your peers. 

First step in understanding the hows and whys of Flash Security is to read the Flash Security Whitepaper. Yeah, I know. The thought of reading a whitepaper about security sounds just about as appealing as a thorn in the eye but it is still the most comprehensive document on the subject. And even if you gloss over chunks of it, you will at least start to see some common themes when dealing with Flash Security.

The most important points to pick up in the whitepaper are that every domain and subdomain is a new domain in Flash. So www.jsjstudios.com, test.jsjstudios.com, localhost, and 127.0.0.1 are all separate domains. Even if you have two subdomains that are proxied to the same location, they are separate domains in Flash.

Also important is when to use allowSecurityDomain, when to use a crossdomain.xml, and when to use allowScriptAccess. Put simply, using allowSecurityDomain allows other swf’s to dig into yours and look at what’s going on, maybe even change a few things. This includes JavaScript functions ( that may not be located on the embedding page ) calling into your swf if you are using ExternalInterface. A liberal allowSecurityDomain should be used to allow any incoming connection or communication if your swf depends on input from outside.

The ubiquitous crossdomain.xml lets swf’s located on remote domains to access that domain. The crossdomain.xml doesn’t reference an particular swf so it is a broad gatekeeper that says other swf’s can access anything in this directory ( including images ). A liberal crossdomain.xml file should be used for anyone that will be engaged in providing web services for all the world to use.

allowScriptAccess is really most useful when you are using ExternalInterface to talk to the html page via javascript. If somebody wants to embed your swf on their page but wants to make sure that your Flash movie doesn’t do any poking around trying to talk to any JavaScript Functions on the page, they will set allowScriptAccess to ‘never’. If you are ok with the embedded swf talking to the html that it’s embedded in but don’t want it talking to any other outside pages, you set allowScriptAccess to ’sameDamin’ ( this is the default ). And if you don’t care at all set allowScriptAccess to ‘always’.

If you ever get a security error, changing one of the three settings above will likely solve your problem.

For those of you looking for web services you can visit JSJStudios.com/jsjstudios.html  

Jamie 

So here begins my rant about Flash / Flex incompatibilities. It’s painful to go from Flash to Flex but at least it can be done. Going the other way ranges in complexity to hard to nearly impossible. And why? It’s all still just ActionScript right?

I’ve spent a lot of time digging around in the Flex framework and it’s obvious that the framework was not designed with flexibility in mind ( pun intended ). And what I mean by that is that every piece of the framework depends on a half a dozen other pieces. Each of which in turn depend on a half a dozen others. Before you know it you are importing the entire framework to do the smallest job.

I understand that the Flex framework does some pretty complicated things and there are some classes that need to depend on the entire framework but there are just as many classes that are not part of what I would call the core framework, classes that just perform one cool little operation. But, for no reason that I can tell, these classes will enforce a dependance on another Flex class… and then NOT call any of that classes methods or properties. I really don’t understand the point besides making it an all or nothing deal.

But that’s not the only problem. Take a look at the core Flex classes and then take a look at the Flash Component classes… remarkably similar. Most of the classes do very similar things, they are even named the same. Great so they must share some basic DNA, right? There must be some commonality, even at the lowest level, right? RIGHT? WRONG! Apparently when the Flex framework was developed, The Flash and Flex teams were not even talking enough to even save THEMSELVES some work. What are the chances they made it easy for us. none.

I’m not saying that Flash is perfect. I’ve never liked the Flash Component framework that much. I think Flex components are much better implemented. But at the end of the day components are components. Can’t we just agree on one way to build them? Even if they aren’t as wiz bang cool as they could be, a smart developer can take the platform and run with it.

So now they are introducing a whole new graphical development environment for Flex, Thermo. Obviously realizing the pain some developers were going through to trying to build UI’s in Flex with as much freedom as they could in Flash. So instead of taking a product which a lot of designers and developers are very happy with, Flash, and finding a way for that product to easily produce Flex components, they roll out a whole new development environment. *sigh*

JSEnumerable is part of the JumpShip Framework and can be found at http://www.osflash.org/projects/jumpship or you can grab it here:http://svn1.cvsdude.com/osflash/jumpship/AS3/com/jsjstudios/jumpship/core/JSEnumerable.asJSEnumerable was largely based on the work of the Prototype team. For those not familiar with Prototype, it is a JavaScript library. One of the unique things about Prototype is that it’s creators were very much influenced by Ruby and have gone a long way in making JavaScript act like Ruby.One of the core modules in Prototype is Enumerable. Enumerable is a collection manipulation module that is at the core of a lot of Prototype’s Objects. It provides filtering, sorting, transforming, and grouping methods.

As in Prototype’s Enumerable, JSEnumerable hinges around the each() method. It essentially lets you iterate over a collection and call a function for each item in that collection. It passes two arguments to that function, the current item in the collection and the index of that item in the collection.The iterator function, the one that gets called for each item, is passed in as the argument to each();. Here’s what a implementation may look like: each( function (item, index) {trace(item+" :: "+index);}); If you’ve ever had any experience with Ruby, you’ll notice that this looks very similar Ruby’s each method. Instead of using a for or while loop you are using the each() method to pass collection items into a code block.

The each() method is used in almost every other method in JSEnumerable in order to iterate over all of the items in the collection and perform some task, whether it be finding, comparing, or sorting. More about each method can be found in the documentation but a few of the operations JSEnumberable can perform are all(), any(), collect(), detect(), findAll(), grep(), inject(), invoke(), max(), min(), pluck(), reject(), sortBy(), and size().JSEnumberable also lets you use array notation [] to access collection items and implements IEventDispatcher because IEventDispatcher is such a fundamental building block for many AS3 classes.

Using JSEnumerable requires extending it and overriding the doEach protected function. doEach tells JSEnumerable how to iterate over your data structure. If your data is an Array doEach may be a for loop, if it’s an Object it may be a for..in loop. The extending class should also override the setItemAt() method. since JSEnumberable does not know how you’re data is structured, it doesn’t know how to make changes to it. This is primarily to enable the use of array notation [].

In my opinion, there there are a few simple rules when deciding on a data structure that will save you a bunch of headache down the road. Here are 4 rules:

• Complexity in data structures usually comes from excessive hierarchy. Flat data structures are simpler, nesting is not your friend. There really shouldn’t be any reason to use more than one dot (.) when you’re retrieving your data.

• Don’t use the same data structure as you may receive from the server, database, or whatever your application is talking to. Prune the data for only what your application needs and put it into a structure that makes the most sense for your application. Whoever designed the back-end data structure probably did it with their own needs in mind, that doesn’t mean you have to be stuck with it.

• Make your data model smarter. It should know how to get you the piece of data you are looking for. I would go as far as to say, If you find yourself using a for or while loop outside of your data model, it’s time to rethink your data model.

• Every data model should implement the folowing methods: addItem(), addItemAt(), getItemAt() ,getItemIndex(), removeAll(), removeItem(), removeItemAt(), sortOn(), and toArray(). These methods are implemented by a bunch of data models (including the ones used by Flash and Flex). Making sure you have these methods means that if you ever need to use your data model again outside of your current application, you will have saved yourself a whole lot of work.