The new me…

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.

Cairngorm Modularity…

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.

:: guest.booq 1.5 ::

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

Servicing so many…

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)…