You are currently browsing archived articles from

AS3 Model-View-Controller Implementation

Sunday, October 8th, 2006

Most developers who are relatively new to Patterns immediately think “MVC” when they here the term “Design Patterns”, and this makes perfect sense considering most of developers have either been using MVC for a long time or have construed their own variations of it’s implementation. What ever the case it is important to understand the basic concepts and implementation of Model-View-Controller, especially as it pertains to Rich Internet Applications, or more specifically, Flex Applications.

Model-View-Controller falls under the category of what is known as a compound pattern, that is, a combination of several different Design Patterns to create a named solution. The patterns that make up MVC are typically the Observer Pattern (Model), Strategy Pattern (View and Controller) and the Composite Pattern (View). MVC originated in the Smalltalk-80 language back in the 80’s and it has since been implemented by just about every programming language that requires a user interface, so it is a perfect solution for building Flex Applications.

Implement MVC in Flex Applications is very simple as Event dispatching and data binding can be utilized to simplify invocation between members of the MVC triad. This allows developers to remove the somewhat awkward Observer pattern which is dependent on passing references of each member throughout the MVC triad.

The MVC paradigm is a way of breaking an application, or more commonly, just a piece of an application’s interface, into three parts: the model, the view, and the controller. Each member is intentionally segregated and represented by an object that is responsible for handling a specific task within the application.

Model: The model is used to manage information and notify observers when that information changes (typically via data binding).

View: The view is responsible for rendering the model to the user. This is usually rendered as a visual display but a view may also be a sound, a controller vibrating or anything that needs to be conveyed to the user.

Controller: The controller accepts input from the user (via Event Dispatching) and instructs the model and view to perform actions based on that input. In effect, the controller is responsible for mapping end-user action to application response. For example, if the user clicks the mouse button, the controller is responsible for determining how the application should respond.

To view a simple example which demonstrates implementing MVC in Flex 2 / ActionScript 3.0 click here.

Should you use Cairngorm?

Thursday, October 5th, 2006

Since the release of Flex 2.0 there has been alot of interest generated within the Flex community about the use of the Cairngorm micro-architecture. There is also alot of new Flex developers who are not yet familiar with both Flex and ActionScript that are jumping into everything all at once. I think that this is a really bad idea for developers who are new to Flex.

Cairngorm provides an architectural solution for common design problems. It has been tried and tested in both Flex 1.5 and Flex 2.0. Cairngorm is currently considered the defacto-standard for developing enterprise RIA’s with Adobe Flex. However, if you are new to Flex and ActionScript you should first concentrate on learning all of the new tools that are now available to you. Trying to learn Cairngorm on top of all of this is only going to confuse you, and even worse, might discourage you.

So when should you use Cairngorm? I would suggest you only use Cairngorm once you have a good understanding of how both Flex and ActionScript work. If you try to tie it all together without really understanding how Flex works you are bound to run into problems. Once you have learned the basics of Flex and ActionScript you should apply your new knowledge to build some small applications.

Once you have built a few small applications are you then ready for Cairngorm? I would say only if you have a good understanding of Design Patterns, why they are used, and how they apply to the development of Flex applications. And you should also have a clear understanding of the different patterns that are implemented in the Cairngorm architecture, most of which have been adopted from the core J2EE patterns such as the Front Controller Pattern, View Helper Pattern and so on. Once you have a solid understanding of Flex, ActionScript and Design Patterns, as well as some experience under your belt, then you are ready to start developing applications with Cairngorm.

As I have mentioned in a previous entry, I will be posting various sample applications which demonstrate some of the most common Design Patterns and how they are implemented in ActionScript 3, as well as tutorials on Cairngorm. You can view my previous posts which demonstrate a simple implementation of the Singleton Pattern and the Factory Pattern (both of which are implemented in cairngorm).

AS3 Factory Pattern Implementation

Monday, October 2nd, 2006

Occasionally when developing Flex applications you will run into a situation where the application calls for certain objects to be instantiated without knowing what type of objects they will be. For example, consider the following scenario: You are building a store in which there are multiple products available. You have created various value objects that represent each product in the store, but you have no way of knowing which products a user will select at runtime, therefore you have no way of knowing which VO’s to instantiate? This is a good example of where implementing the Factory Pattern comes in handy.

In case you are not familiar with a Factory Pattern let me give you a quick overview. The Factory Pattern is a creational pattern that models an interface for creating an object which at runtime delegates instantiation to it’s subclasses. This is called a factory pattern since it is intended to “Manufacture” objects. When using the factory pattern your code is loosely coupled since it eliminates the need to embed logic and application specific classes into your code.

For example, you can just as easily add logic to your code that determines which class to instantiate based on the product selected. The only problem with this approach is that you may not want to have the product classes available to the application in general, but rather provide a specific class which is responsible for deciding which class to instantiate, and then return the object to the application. This way your application can stay loosely coupled and the product classes can be abstracted from the application. This approach encourages encapsulation and delegation which is always a good thing in Object Oriented Programming.

I developed a basic sample application which implements the Factory pattern in ActionScript 3 that you can view here.

You can also click here to view the source code as well as the ASDocs

Design Patterns in AS3

Sunday, October 1st, 2006

As a software developer I spend a great deal of my time implementing various design patterns to solve common problems. As I explore a particular problem domain I can easily identify which pattern or patterns can be applied in order to create a viable solution.There are currently 23 common software design patterns around today. These 23 patterns can be organized into three separate categories: Creational, Structural and Behavioral.

Many of these standard patterns are commonly used by developers in all areas of programming and many apply to RIA development. The greatest thing about design patterns is that they are typically not much more than an efficient, structured way of doing things that most of us have already been doing for a long time. Design Patterns allow us to simplify common design problems into standard, common named solutions. By implementing common design patterns and best practices we can keep our applications consistant without re-inventing the wheel every time. They allow us to solve the same problems over and over again in the same way. Design patterns also allow us to write code that is common amongst other developers. This is helpful as it allows other developers who are familiar with these patterns to easily and intuitively work with our code, and vice-versa.

Personally, when designing an application I prefer to use the Adobe Cairngorm micro-architecture, whereas there are various patterns combined to create an architectural framework which can be implemented to provide a common solution. An Architectural framework is a framework that does not provide additional services or API’s (such as the Flex framework) but instead provides a consistent, generic architectural framework that an application can be built upon.

Over the course of the next few weeks I will be posting examples of various pattern implementations in ActionScript 3 and how these patterns can be utilized in order create solutions to common problems.

AS3 DisplayObjectContainerManager

Friday, September 29th, 2006

A co-worker of mine ran into a problem the other day in which he needed to remove a component from it’s parent container and relocate the component to a new container. This type of functionality is pretty common in flex applications so I decided to write a simple utility class to handle relocating display objects from one container to another.

The DisplayObjectContainerManager is a singleton pattern implementation in which there is a single instance created which handles display object relocation from within the display list. DisplayObjectContainerManager allows a component to easily be removed from it’s parent container and relocated to a seperate container while retaining it’s current state.

You can view a basic usage example here or view the ASDoc for the DisplayObjectContainerManager here.

AS3 WSDLURIProxy Class

Saturday, September 23rd, 2006

Many times when you are developing Flex 2.0 Applications utilizing Flex 2 Data Services you will most likely be consuming a web service in various components through out your application.

For instance: Imagine an application in which there are three different view states in the application and you have implemented a ViewStack to handle the different states. Within the ViewStack there are 3 seperate custom components. Each custom component contains a datagrid which displays data retrieved from a Web Service via a mx:WebService tag. In the Web Service tag you set the wsdl property to a specific Endpoint URI.

The only problem is that if you are working in a development enviroment and your application moves to production you will most likely need to change the wsdl destination in all of your components. This approach is fine and is also very common in simple Flex Applications which consume a webservice as a data source. A more efficient way of setting the Endpoint URI is by adding channels and destinations to the services-config.xml file located in WEB-INF\flex that the Web Service tags can point to. The WSDLProxy class adds the same functionality but in ActionScript, therefore there is no need to modify the services-config.xml.

How the WSDLURIProxy works is very simple. You set a static constant of type String to the URI of the Web Service endpoint. Next all you need to do is import the WSDLURIProxy in all of your components and set the ‘wsdl’ property in all tags to: wsdl=”{WSDLURIProxy.getEndpointURI()}”. and that’s it.

Now once your application is pushed form development to production if the Endpoint URI needs to change you can simply change the URI in the WSDLURIProxy and all of your Web Service tags will reflect the changes. Very Simple. If your working on a simple application and not using Cairngorm then this is a very useful utility.
Below I have provided links to the source code as well as complete WSDLURIProxy ASDocs.

WSDLURIProxy.as

ASDOC