I put together a simple Flex application to show how easy it is to create a flash remoting flex application.  The app doesn't use a particular framework and I used the Flex CF Wizards to create all the ColdFusion code, which made my job really easy.  You have probably already noticed that the blog entry is labeled "Part 1", I plan on having three postings.  The first one (this one) will focus around a basic Flex application that uses Flash Remoting to talk to ColdFusion. In this example we wont bother with frameworks, we will try to use binding as much as possible, view states and some other basic Flex concepts.  The second entry (Part 2) will take our Part 1 Flex application and will add a little more depth, such as adding a Cairngorm framework to the flex project. The third entry (Part 3) will migrate the Contact Manager that I do in Part 1 and move it over as an AIR application.   There might be a fourth posting on a Cairngorm AIR application, but to be honest I haven't worked with Cairngorm in AIR yet, so I plan on playing with it a little before I make another entry ;) . 

Now that I have given you a little prelude to what's to come, let's focus on Part 1! Time to dive into how the application works!

The application is broken down into 1 main app file, 4 component files (views: footer, header, contact listing and details form), a main.as file, 2 VO (Value Object) classes, the coldfusion cfc's (VO, Gateway, DAO) and then we have our assets (images, styles, etc...).  By breaking the code up into these different areas, our main.mxml file ends up being very small, 30 lines of code to be exact, which allows us to easily read through it and if need be in the future we can add to the functionality of this application.

Fig 1.0 - Displays the basic architecture layout of how the Contact Manager is structured.

Our view components (contactListing and contactDetails) talk back to the main.mxml file through the events (ModifyContactEvent and ModifySettingsEvent). Both of these events handle the changes to our contact/settings vo and our ModifySettingsEvent lets our main.mxml file know to change the viewstack index based on the users inputs to the application. The logic in each event is almost exact, except for the vo being passed when the event is called.

One of the advantages of passing a value object around instead of just a string or a number is that we can put lots of other data that is related to a contact then just a name, we may want to add a email or a phone number later on and using the VO will make this change much easier. There are also serialization advantages that I will talk about later.

In both of our view components (contactListing, contactDetails) we can create the events by using the Meta tag like this:

Now in our main.as file, which was included in our main.mxml, we can create event listeners that listen for the event that was created in our other view components

Now when a user selects a contact or decides to create a new contact we can make a UI view change based on that user interaction.

Once you understand the basics of creating events, adding event listeners, the advantages of VOs over passing normal data types creating small Flex projects becomes a breeze. For larger projects we would want to utilize the benefits of a MVC framework such as Cairngorm and utilize design pattern best practices.

The last part of the Contact Manager we will look at is the Coldfusion CFCs. I mentioned earlier that I did not code the CFCs at all, I utilized the Flex Coldfusion wizard to create the ActionScript version of our Contact.vo, the Coldfusion VO (or bean) (Contact.cfc), DAO (ContactDAO.cfc) and Gateway (ContactGateway.cfc). After they were generated I went back in and made sure the CFC paths where correct and I added in a application.dsn variable for my dsn name (Shame on you Adobe for not putting that in the wizard as an option!). So you might be thinking what the heck do each of these CFC's do and why dont we just use one CFC to handle simple database entries? Well the short answer is, why do you care you didnt code it? The long answer... pull up a chair... haahaa... no seriously its really simple. Since we are passing VO's around in our Flex app, we want the data coming back from Coldfusion to return an array collection of contacts, not just an array of objects. So our contact.cfc is basically our VO, but its our Coldfusion version. Some would also call this a bean (Java stuff that I won't get into). So something that is really cool, is that in our contact.as class we reference the remote class alias to point back to our contact.cfc, so when Flex and CF talk it automatically serializes to the correct data type :) and that is when it knows to return an array collection of contacts -- cool huh! The best part is we didn't even need to code anything!

That is the end of our Part 1 example of the Contact Manager, the code and the example can be seen here. I will be posting on a Cairngorm version of this ridiculously simple Flex application soon, enjoy!