cf.Objective() Session - Flex: No Frameworks Required by Maxim Porges

Considering that I am giving the Cairngorm session tomorrow and that I was so impressed by Laura's Mate session yesterday, this seemed like a "must see" for me. Max starts by saying that this is not necessarily a "to use frameworks or not" but focuses more on many underlying design patterns you can use (and that some frameworks already contain).

Why Use Frameworks?
Max says that, in his opinion, a lot of people jumped on frameworks in Flex because they were burned by framework-free development in ColdFusion. However, he says that frameworks can offer, best practices, familiarity, common solution and a community of developers who are familiar with the framework. Nonetheless, he says, underlying all this, we want repeatable patterns we can use for development and you don't need a framework to do this.

Some differences between Flex and ColdFusion that are important to consider is that Flex is stateful, asynchronous and supports data binding. Each of these things can present challenges for people moving to Flex and to developing Flex applications. There are patterns you can use to handle each of these issues.

Event Handling
Events are the basic staple in Flash and Flex. They can be customized and it is easy to handle reactions to events. They promote asynchronous processing and loose-coupling, because the view doesn't need to know how an event was processed. You use the observer pattern to handle events. The observer pattern needs something to target and know how to react to a particular event. The events are announced by the UI and are generally passed through a Controller if you use an MVC pattern of development. You may want to create a mediator if there are opportunities for reuse, but it may not be necessary and Max wants to emphasize building only what you need.

Data Binding
Data binding is essentially just an observer implementation again. Max believes that while bindings are great but promote coupling. The solution to decoupling your data and your view is to put things in a Controller. He doesn't like the Model Locator because it tends to become a "catch all" or "dumping ground" for every piece of data you want to use. For large applications this can get out of hand. In addition, it tends to get used for handling state changes which destroys the encapsulation it was intended to promote. Max uses a pattern similar to Rails in which everything goes through a controller, though instead of having one, you have as many as you need to handle all the layers of your application. He generally has his controller extend Event Dispatcher because it generally will dispatch events.

Finding Stuff
You can use a Registry pattern as a common interface for finding things. It also serves to hide how objects are instantiated and located. Usually this will return references to Singletons but doesn't have to. Generally, Max prefers to use a static reference to Registry within his Registry class. The Registry can pass an instance to the controller or controllers as needed.

Asynchronous Process
The problem with asynchronous processing is maintaining state and tying the multiple send()s to specific responders. You want to use a Responder pattern and the Asynchronous Completion Token. The Responder pattern is a Flex specific pattern that is similar to an Observer. Responders are built-in to Flex and is a basic implementation of IResponder. The Asynchronous Token reference is passed back to the Responder and can contain references to what event triggered it or what View it relates to. The Responder contains both the success and fault handlers for a particular event.

Max showed a very nice example application that was a tile list of products with a detail pane and a shopping cart. His example application implemented all the patterns he discussed during the presentation. He concludes by saying there is nothing wrong with using a framework if you want to but *do* use design patterns to improve your development.