Jim has been working with Flash since 1999 when Flash 4 was new.

As applications develop, requirements grow and complexity increases so it is important to be able to add new facilities. Cairngorm makes it easy to collaborate on a single file or projects. It makes it easy to find things in your code and add new features.

Every time you use Cairngorm you have to add the Cairngorm Library to the build Path in project properties. Ant can be used to create the application skeleton to save a lot of typing. Eric Feminella has written some Ant Scripts, which create several objects needed by the framework. Several folders are created with Actionscript files in each already.

• business
• commands
• control
• events
• model
• vo

In the class we created a news reader which would take newsfeeds from Reuters. There were one or two problems keeping up with the class. (I am not used to the US keyboard.)

www.cairngormdocs.org is the place to go for the full description of the framework.

My overall impression was that there does seem to be more overheads here than is really necessary for a simple application and I am concerned that with a really large application the huge number of files will grow and make it difficult to maintain things.

At lunch I talked with Mike and Angie Nimer who have some experience of using Cairngorm. They confirmed my thoughts and both said that there is a heavy price to pay in terms of extra overhead required in order to build an application with Cairngorm.

John Paul gave an overview of why he thinks Ruby on Rails is good framework for web application development. One of the things about rails is that it includes as standard many things that we in the Fusebox world regard as extras.

Active Record for example provides similar facilities to Reactor does for CF application and is part of the standard Ruby on Rails installation. It works hard to make the database fairly invisible. For example changing from MySQL to MS SQL is completely painless.

The only task that has to be done in the DBMS is to create the database. Everything else is done in Rails.

There is built in support for caching, logging and security.

When installing Rails a very simple clean install package is available which combines all the features.

It has a collection of templates for use in creating views. Rhtml (Ruby), rxml, rjs(Ajax).

There is a built in vendor directory structure that allows each vendor to have a valid place to put files. There are a lot of cool plug-ins for rails. Streamline takes Rails scaffolding and bonds it with Google toolkit.

Capistrano is a built in deployment tool, which could be used with CF.

JRuby is a java version of Ruby. This could be a big competitor for ColdFusion, once Rails is able to run on JRuby.

Rails lessons:

• Best Practices all together in a single package.
  • Version Control
  • Deployment
  • ORM
  • Ajax
• Make the database invisible.
  • Transfer
  • Reactor
• Easy things should be easy.
• Testing is crucial, and should be easy.
  • Rails contains a test harness and can be run.

John Paul has implemented some of the Rails ideas in his ColdFusion Applications.

• Move to convention over configuration.
• Pick an ORNM and integrate it.
• Pick an Ajax Library and integrate it.
• Pick a test library and use it. (cfunit or cfcunit or selenium)
• Automate the generation of the XML files for the parts.

Book on JUnit can be used with cfcUnit and there is a good presentation on UGTV.

John Paul sugessts we choose a scripting language that we can run from the command line. Ant is a good way to run scripts but maybe Ruby is good choice for scripts too.

When building MVC applications it's possible that the model can bleed into the controller. For example this can happen when a listener is being created in MachII and it seems easy to add SQL to the listener. Other Frameworks can have the same problem.

The other thing that can happen is with persistence or caching which gets hard coded as session or application scope and is difficult to change.

It is important to keep the controller and model separate. Controller should be as dumb as you can make it. The model should be able to be used by any framework and the controller should be able to use any model.

Ideally your model CFCs should be able to be used by any framework and one way to help is to ensure that they only do a single thing.

Services layer should be used to encapsulate the model and prevent the controller from bleeding in to the model or vice versa.

There are some big advantages for the Framework Agnostic Model.

Possible to switch frameworks
Use with CF, Ajax and Flex
Easier debugging
Easier testing
Easier maintenance

Brian has created a sample bookstore application that is built with three different frameworks, Model-Glue, Fusebox, MachII. The application also uses ColdSpring and Reactor to create and organise the model and can be downloaded from his site.

ColdSpring is also used in the examples to create a remote façade for Flash Remoting or web services.

There was an interesting discussion on the code in the example and how it worked with the different frameworks to move data from the model to the view.

Kurt told us that you won't really know you need ColdSpring until you see one of the problems that it solves. It's good to think of ColdSpring as a big box of objects. You can use CS to to assemble your objects. CS is smart and can prepare objects in advance. It makes sure that there is only one instance of each object.

Typical Application Architecture contains Business Objects (or Beans), Service Objects (The API for the application eg. GetUser), DAOs which do single record access to the database, Gateways which do multiple record access, Controllers, which handle http requests, and Views which present the data.

Kurt's experience was of having lots of service objects and wrote remote services manually. Flash remoting CFCs were separate from the main services CFCs. It was difficult to test the DAOs and Gateways.

Using ColdSpring Kurt was able to use an object factory for creating objects and most of these issues went away.

With CS the objects are configured with an XML file, which tells CS what the dependencies between CFCs are. It will set up the required dependant CFCs and pass them as parameter. Doing this is known as Dependency Injection or Inversion of Control (IOC). The Hollywood Principle (Don't call me I'll call you!)

By default all objects created by CS will be singletons and will get cached in application scope. You can specify that beans will not be singletons by adding a parameter to the bean tag.

CS supports AOP, and generation of remotely accessible objects. Plug-ins exist for Fusebox 4/5, MachII and Model-Glue. It also has support for integration with other factories through the factory method attribute. This allows integration with a factory that will create DAOs and gateways.

You can configure the ReactorFactory as a coldspring bean so that you can use ColdSpring to create Reactor objects.

Aspect Oriented Programming allows you to intercept method calls and act before and/or after the call. It is completely transparent. Used for security, caching, logging and generation of remote services.

This can be a very good way to debug an application where logging can be set up to log the calls to a particular CFC or even all CFCs. This will work both with CF and Flex based applications.

Remote Facades can be generated to support Flex. This is done with a remote Proxy Factory. This was much easier than doing it manually.

The service layer should contain all the business logic rather than in the controller, this makes moving from a CF to Flex application easy.

AppBooster is a sample application using MachII and ColdSpring.

Provides a simple model for users, addresses, and roles and can be used to form the basis for a typical application.

What tips are there for new ColdSpring Users.

• For a new ColdSpring application its recommended to do a simple project first to get to know it. Eg a ToDo List. Build one set of screens to create and update a task.
• Brian Rinaldi has a great code generator on RIAForge.
• Favor setter injection over constructor injection when setting up your services. CS finds it easier to call setters. This uses property tags rather than constructor-arg tags in the CS XML.
Join the ColdSpring mailing list.

http://coldspringframework.org
http://cdscott.blogspot.com/
http://www.d-ross.org/
http://jroller.com/page/kwiersma/

You can download appBooster from the blog. Kurt will update it with the flex interface soon.

Another good code generator is cfcPowertools.

Joe gave a good Intro to Ajax Technology and began by pointing out that most people don't use XML to transfer data from server to client, but use JSON or HTML instead.

The XMLHttpRequest object is used to make the request to the server. Many frameworks can be used to hide the complexity of these calls.

Joe likes the Prototype framework which is very simple to use. A single call can say get this URL and stick the results in a div tag.

For the example application he also used script.aculo.us, an extension to prototype, which provides some additional JS features.

He demonstrated how to create an event handler that deletes a record,
Include the AJAX and JS frame works,
Fade the deleted row,
You should also give some clues to the user that AJAX is being used.

Firebug was used to show the traffic between the Firefox browser and the server.

Aspect Oriented Programing (AOP) gives you a way to apply cross cutting concerns to a wide area of your object model. Eg Logging, security and similar.

You can work declaratively, rather than procedurally.

For example remove the cflog statement from multiple places in your code and use AOP to introduce the functionality of logging throughout your code. It does this by intercepting the method calls. These are called "Join Points" in AOP.

"Introduction" allows code to be added before, after, during and around any method call to a CFC. We call this "advising".

You extend "Advice classes" to do this. You are able to do this at the following points:

BeforeAdvice,
AfterReturningAdvice,
AfterThrowingAdvice,
AroundAdvice.

This is similar to the decorator pattern. The Decorator adds functionality and calls the original method, to do the main part of the work.

To use decorator for logging you would have to manually create multiple decorators and swap them for each of the existing calls.

AOP offers Dynamic Proxy Generation. A proxy is created to add the functionality. ColdSpring creates the proxy object and add the advice classes. The process is called "weaving". A class called an advisor is a build tool for the proxy factory.

The aspect is created and Target Object is passed to the ProxyFactoryBean to create the new object. Since it extends your object you can use the generated object just like your own.

The Lightpost sample application shows the way this can be used.

An aspect is a way to think about an abstract system. AOP gives tools to allow those abstract systems to be incorporated into your system.

Metadata can be used to configure the abstract system. CF metadata can be extended by use of Additional attributes which are added to the cffunction tag to extend the metadata, for each method.

This can allow the same aspect functionality to be shared between a CF app and a Flex app.

There will be an article on Adobe.com about this very soon and the LightPost examples will be available by the end of the month.

There is a good article by Barney Boisvert about adding metadata to objects and using it in ColdSpring.

There is good robohelp documentation at www.coldspringframework.org.

Peter spoke about: Language Oriented Programming which can allow you to create more reusable code. What is required to build a code generator. Software product lines can be used to deliver projects in certain cases. Look at way to generate a web application.

Scaffolding will automatically generate code to create forms, lists and view pages for an object. It is typically done by using the database to provide the metadata. Eg Reactor.

There are limits to what can be done that way. User has to add extra code later to make up for the limitation of the database metadata.

Language Oriented Programming is a new approach to programming which improves the metadata. Everyone is doing it:

OMG: Model Drive Architecture.

Microsoft: Sofware Factories.

JetBrains IntelliJ Meta Programming system.

CF Custom Tags or UDFs are ways to do some similar things. Modify the language to create a domain specific language. CFCs do this too.... The reason is to encapsulate complexity.

Layered software allows you to create a domain specific language to solve the problems. Good programmers often begin with a pseudo-code to describe the problem then replace the code with real calls to real routines.

Horizontal DSLs:

SQL,
Reg_Ex,
Objects,
Notifications,
ColdSpring XML,
Reactor XML.

Vertical DSLs:
Newetter,
Insurance Quotes

Three types of DSL:
Declarative,
Templating,
Scripting.

Declarative languages are ideal for reuse. Templating languages simplify for designers. Scripting languages are used to implement the solution.

What vs How

It really does not matter which language gets used.

ColdFusion, XML, Special, Diagrams.

There are three types of code generator:

Passive (not much use),
Active (easier),
Roundtrip (difficult).

Metadata can be stored in text files, XML or a database.

The code can be generated using a templating language. Eg XSLT or ColdFusion.

CFTemplate can be used.

Iterator is required: One DAO per object, one template per screen etc.

Orchestrator is required: described by Metadata.

You will never generate everything because it is quicker to handle separately, eg Safe code snippets or Inheritance.

Anatomy of a generator: Metadata, Templates, Iterator, Orchestrator, Extensions.

Need to be able to generate the code in minutes. Use a feature model and allow wizards to select features.

There is an object model and an interface model.

Content
@LiveDate: Optional: Datetime: 1/1/2000
@Status: Required: Status: approved

Use custom data types to describe the interface model.

Screens can be defined by:
@Type=List,
@Paging=Yes,
@RecordsPerPage=50.

Layer software product lines for higher levels of reuse.

CFGen and CFTemplate will be available at http://www.pbell.com in the next few weeks.

10 years ago when we started this Fusebox stuff we decided that if everyone wrote applications in the same way it would make maintenance easier. Now there are lots of different frameworks to choose from. MachII, Model-Glue, FarCry....

Are frameworks really necessary? – Absolutely. But it does not matter which one!

From day one Fusebox separated out view, and model and action parts.

The architecture code should be consistent regardless of who wrote it.

Multiple developers in a team, separation and distribution of work.

XML has become a standard in frameworks. XML offers ability to create tools that can be used. It seemed good at first but why have two languages.

Framework code must be run to parse the code and generate the parsed files.

Why can't the CFCs manage themselves? Well Steve's sample shows how they can.

In application.cfc you put all your CFCs into application memory.

There are 3 types of CFC controller, model and view.

Call include wrapped in cfsavecontent and return it.

Naming convention allows fuses and folders to be found easily.

Steve will post the Sample code later today.

There are some issues here with var scoping which need a solution.