CairngormModule Example

This is in no way a tutorial on Cairngorm… in-fact, the use of Cairngorm here is really rough. This is however an Application, using Cairngorm, that is split into Flex Modules. The important thing is the use of a Cairngorm implementation within the modules. 

For brevity I’m not using services. There are some important considerations with services and delegates. You can easily define the BusinessDelegates in the module package but in the structure I have shown, you must define the services in the main application.

In actual development, I use a custom implementation of ServiceLocator so that each modules can inject their own Service Objects. This gives me the ability to dynamically load modules at run time and makes the configuration stay where it belongs.

I hope that this small example helps people. I will probably move on to the architecture that I use most now, MVP (Model View Presenter).

Ok, so it’s been a while. I’m sorry to those that were waiting for the cairngorm module examples. I don’t have a lot of time lately and I don’t use cairngorm so much now.

I hope to blog a bit more often now that I have a worspress app for my new iPhone 3G. I will be discussing the MVP pattern in my next few blogs and I will be doing a cairngorm compare and contrast.

If anyone still wants to see some cairngorm module code, let me know.

Using modules in Flex isn’t all that difficult to understand. But as I have read on many a blog, using Cairngorm with modules is giving people fits. Well, not me…

You use modules so that you can load a portion of your application (functional or visual) and unload it independent of the main application. You do this (using Flex Builder) by extending mx.modules.Module either in a different project or the same, making sure your component is registered as an application in the properties. This Module Component then can be loaded into your main application (shell app) by use of the ModuleLoader class. Simply set the attribute ‘url’ on the ModuleLoader (which is a DisplayObject) and YourModuleLoaderID.loadModule() and YourModuleLoaderID.unloadModule(). If the module is a visual component it will be loaded wherever you place it. Likewise you can place a non visual module anywhere and reference it by id. This is where the difficulty starts.

Now that you have a loaded module, unless it’s a trivial thing, you are going to want to interact with it. With Cairngorm this is very interesting. All sorts of things can happen when you get an application running with the FrontController and ServiceLocator patterns then you just up and load an entirely autonomous Cairngorm implementation in the same player. So don’t. The interaction between module and shell application is communicated by implementing interfaces. If you are going to be using Cairngorm in the base or shell app, then you need to use IoC (inversion of control) to plug a Cairngorm based module into the shell. Specifically, your module will more then likely be using the FrontController to register events/command pairs and it will need to use the shell app’s ServiceLocator to access services. You can easily create an interface that allows you to pass these two items to the module being loaded and if your like me, you can even extend the Module component to make a lot of things happen in the background.

As for calling module events from the shell you can build that all into your interface. All of your delegates, views, ViewHelpers and the modules models will probably be couched in the module, any information that you need from the shell should be provided by IoC.

I will post some code that shows all of this happily working, but for now, I must leave so I can continue to be happily working!

If you use Flex, then Cairngorm makes your life easier. Cairngorm makes your Flex programming more responsible, easier to maintain and extend and it promotes more efficient teamwork.

But what does it do?

Well, Cairngorm is a library (a compiled flash swf) of classes and interfaces that are plumbed together to allow the programmer to plug-in commands (control logic) and interfaces (views) in an easy, efficient manner. By using Cairngorm you are leveraging hundreds of thousands of hours of developer time figuring out what patterns work best for enterprise applications. The Adobe team used guidelines from the J2EE Enterprise Design Pattern catalog to create a very powerful framework (some say micro-architecture) for Flex distributed applications. This framework is logical so it is easy to learn and more importantly easy to teach.

Cairngorm in the work place: A trilogoy – in four parts…

Model: First off the image at left was quick effort, if it’s incorrect for some reason I will fix it (please let me know). There are 4 parts on the Flex side that you as the UI designer will have to create/modify in order to use Flex and Cairngorm to implement good MVC (the afore mentioned trilogy, work with me). To get the Model portion (session model) up and running you simply create an AS Class that extends ModelLocator. Insert data objects into this model as bindable public properties. These will drive the interface to change states, enable controls and fill forms.

View: Secondly you create the views that you need based on the model. It’s easy to test your model and views by inserting test data and manipulating it, this give you some valuable feedback on the view state relating to the model state and making sure validation is in place.

Control: Control is implemented through a multi-step process. First a user clicks a button (user gesture) which will fire a Cairngorm event through the CairngormEventBroadcaster. You must create these events, passing any information necessary for a process into one (like: new showOrdersForAccountEvent(account:Account).dispatch()). The Event is registered with the FrontController to execute a command (FrontController is a class you create that extends FrontController).

The Command Pattern is used in various ways (i.e. in java swing.Actions). In Cairngorm you implement ICommand with a class and you put your controller logic into the execute(event:CairngromEvent) method. This way an event, from anywhere in the application, can be routed by the FrontController to any Command that you want executed. The FrontController may also log or filter these events before command execution.

Thats Cairngorm MVC. There is a fourth part to getting this to work with a server and that will have to wait till another entry but first I must put some more of my old entries back up.

A general introduction: The Session Facade enterprise design pattern allows you to create a clean, well-defined interface to complex and/or composited business objects. The Service Locator is an object that gives you a one-stop shop for all your service needs. It holds a reference to all of your services whether they are Remoting, web services, http service calls or other external resources. The Business Delegate is a layer of separation between the Service Locator and the control (command) code, which is very helpful in Flex as it’s an excellent place to setup your responders to the asynchronous calls that you will make and handle service problems.

Facades

The Facade pattern is widely used and usually without notice… Anytime you create a class that has a simple interface to mask complex or more volatile objects, you are using the facade pattern. The Session Facade pattern is an implementation of the Facade pattern where service calls are made to an object that masks business object method call and services call aggregation/composition. I enjoy the luxury of using ColdFusion to perform this task. With one CFC you can create a Session Facade that enables Flex to make Remoting calls and allow other clients to consume the facade as a web service. If you don’t carry your DTOs (Value Objects) into the business layer you will also use the Session Facade as a place to create DAOs from your DTOs for use in the business layer (which usually employs a pattern known as Transfer Object Assembler). ColdFusion makes this process easier as well, you can simply iterate through the DTO struct and copy required entries to the DAO structure (this works in both directions of course).

Service Locator

The Service Locator is helpful to the client. You should point your business delegates and any view helpers that make service calls to one object. That object is the Service Locator and it contains the configurations for access to any services you are going to use.

Business Delegate

A Business Delegate will help minimize impact on your client code when the server side interface changes. This also gives you a smart place to do some exception handling and missing service decisions. When used with the command pattern and the Service Locator this object is really helpful as a place to create a simple service interface for the commands.

Some say that Flex, due to it’s natural separation of interface and server, gives you the freedom from the tedium of working with MVC. Well, ok, I have an opinion on that like everything else…

Flex is awesome, and it does many things, but facilitating laziness is only a superficial benefit. Sure you may start building Flex apps with little to no design pattern influence and you may design a complex Flex application that is so removed from the server-side logic that you feel justified in your decision to use “the quicker, the better coding”. I have done this myself. But all of the original rules apply (but with built-in benefits).

The server will be isolated, that’s the nice thing about the Flash-Plugin as a delivery medium. But the Domain model living on the server is different than the M in MVC. The complexity of managing (C) how the interface (V) interacts with a session state (M) is nothing to overlook. You might say, “look at the current :: guest.booq :: sample application for example, it would be 50% of the time to write it without MVC or a framework.” Yes, originally it would, but going from one version to the next takes me less than 25% of the time it would normally take. This gives me more time for the important things like appearance (how’s that for superficial).

A Distributed Client like Flex, or Swing is naturally isolated from the server by it’s delivery mechanism. Please don’t make the mistake of believing this is the model-view separation you must employ for reuse and maintenance. You must encapsulate a small portion of your domain model into a session model of some sort. In standard web technologies this means having an isolated variable storage that you can access using a key. You take a piece of this session storage and you display and/or manipulate it in some way then you offer it back to the domain model for persistence. With distributed clients you usually hold the session model in the client. This is very different with a web page as the client, because having an xml structure of all your session model data in the HTML of the page wouldn’t make sense. Flex (or Flash in general) has a very capable OO architecture which is wonderful for caching and typing session data. So with this session model in the interface delivery mechanism you have the necessary parts (M and V) to do things the right way. Then, with some help from the smart ppl at Adobe, we can drop Cairngrom into the mix and come out with a very strong, time-tested way of producing RIAs utilizing Enterprise Design patterns.

MVC has been defined in so many places that I won’t do that here. I would like to talk about some Enterprise Design Patterns over the next few blog entries that are important to understand: Service Facade, Model Locator, Front Controller and the Command Pattern.

:: guest.booq 1.5 :: With a lot more meat to it, here is the next iteration in the guest.booq series. I will be blogging about the methodology as time permits… hopefully someone enjoys.

Ok, so I’m just spicing up a lame name with punctuation (that’s always a bad sign) but I wanted a little more then a hello world type application.

: guest.booq : here it is. This is about the most simple application using Cairngorm you will probably find. There are no fancy effects or transitions and the form isn’t saving to the database yet, but I wanted to get a simple listing/drill-down project up for preview. In the coming days I’m going to add functionality to this same interface to show you how easy it is to extend and alter with Flex and ColdFusion.

Some things to note: The View is being controlled by a ViewModel and the fields are bound to data model objects in the ModelLocator (another solid denterprise design pattern) . The Services are registered as RemoteObjects in the Services.MXML a very clever implementation of the ServiceLocator design pattern offered by Cairngorm.

I hope to get the users editable in a day or so (possibly changing jobs so I’m sorry if it takes longer). Eventually I hope to consume some third-party services, get some Stock Ticking maybe weather, Account management, usage tracking… all kinds of high-hopes for this little jewel!

ColdFusion CFCs are gods gift to web development. Yes, there are security concerns, but with a good design you have at your disposal a tool for creating an interface, web method, web service, well defined objects and more. I love to create a Service Layer and connect a Flex Application to it because I know how much work I’m not doing.

My service layers are simply interfaces (as I believe most are). No logic really, just a remote interface to the business layer and some security. If I’m writing a external app there are more considerations than an internal. The external remote service calls are wrapped up in a RequestDTO Object of some kind and they payload a security context dto of some kind. In this case the Service Layer will be breaking up the composite DTOs and accessing various BI calls to complete a process. This is a pattern called Session Facade and it relies heavily on the choice of DTO design.

If I didn’t explain the importance of DTOs then I should have. A Data Transfer Object (sometimes called ValueObject) is an object defined by its use more then by the pieces of data that make it up. A ShoppingCartDTO will have an array of Items, a user maybe and various other configurations but the shopping cart looks nothing like that in the database (or even the abstraction layer). The Services layer is going to deal with incoming requests, received as DTOs and interact with the BI layer passing along DTOs and getting DTOs back. What is the difference between the DTOs and DAOs? Well with EJBs sometimes there is no difference (not a good design to me). Mostly the difference is in simplifying the object to work for the UI and the services layer without carrying around anymore information then necessary. A DTO also gives you the opportunity to composite DTOs and configuration properties to transfer a complex set of objects as a single object. Another handy function: it gives Flex (a separate technology from ColdFusion and Java) the ability to use native ActionScript objects as proxies for middleware objects in both directions.

With these DTOs available to Flex as objects, and not just graphs of simple properties – very strict definitions can be written on the Flex side. This fits in very nicely with an MVC framework like Cairngorm. With well defined objects, views can be bound to DTOs instead of having to muddy the waters with hundreds of listeners.

more on a later date (hopefully with examples)…

I’m working on it… I want to cover these other important issues about application development before I drop the bomb. And it is… The Bomb…