You can use HTTPService, WebService, RemoteObject components in Flex to pull data in different ways. Now what about ColdFusion 9?

ColdFusion’s Flash Remoting has been improved. So Flash applications that have ColdFusion 9 as a backend will interact much faster, and it can handle circular references.

There is now direct data translation between ActionScript and CF types, instead of previously having an intermediate Java layer that handled this. This involves changes in services-config.xml, but no code changes are required in your apps. Support for the old style remoting is still present for backward compatibility.

So how much faster is it? Drastically faster. Easily x9 faster, and that increases as the number of transactions occurs, according to the whitepaper Adobe has released about it.

BlazeDS. ColdFusion 9 is now integrated with BlazeDS as the default installation.

Configuration File. Services-Config.xml is now split into 4 files. There are a handful of ColdFusion-specific properties under the channel definition now. An “enable-small-messages” property is there and should be set to “false”. This is important for the new Flash Remoting in CF9, because BlazeDS’s default is “true”.

There is an AMFChannel component in Flex for the new Flash Remoting (Note: You can alternatively tell the AMFChannel component to have enableSmallMessages=”false”). Finally, the endpoint class is changed for the new CF9 one.

Offline AIR apps with ColdFusion 9

Now the fun stuff. ColdFusion 9 has an ORM for AIR! Build offline AIR apps without the SQL mess and conflict handling. There is a CF-AIR persistent framework for SQLite on the client side. CF keeps track of all updates to local database and synchronizes with the server, including conflict resolution.

By having ORM on the client- and server-side, these two are integrated through the CF-AIR persistent framework.

In the application code for the demo, there were customer.cfc and address.cfc persistent objects. Then a sync CFC is used for providing the fetch and sync functions for communication with the AIR client.

Step #1: Create the persistent CFCs.

Step #2: Create the sync CFC. He called it custmgr.cfc. The CFC has implements=”ISyncManager” as an attribute. Then you have fetch() and sync() methods that handle the transactions. Here you can provide your logic for handling certain scenarios, such as conflicts.

Step #3: On client side, create equivalent AS classes that map to the CFC via the [RemoteClass(alias="")] metadata tag.

Step #4: Use the CF-built AIR libraries provided to fetch data from server, with the SyncManager component. It’s very simple, practically just point it to the sync CFC and do a fetch() method. To work with the database, you then openSession() and can create new AS objects and call save() on the session to insert/update/etc. Finally, using commit() will commit the results and invoke the sync() process.

On the client side, it can receive conflict notification and receive both versions of the data so that you can decide what to do with the conflict.

It is very exciting to have some help implementing synchronization without having to purchase LCDS. Using the CF9/AIR integration libraries will be very nice.

Packages. The old mx packages are still there. But now everything new is in the spark packages. Why two different packages? At first, they had them all in the same package, but the component had a prefix for the new version. It wasn’t received well. So instead, Adobe just put the new components in new namespaces.

The MX namespace is also called “Halo”. Don’t consider it a “legacy” namespace. These are still fully supported. Spark is all of the new stuff. The general MXML has a new 2009 namespace, but the legacy namespace is still supported.

Graphics

You can add graphic primitives enabling you to draw lines, ellipses, and curves, directly within the MXML. With the new FXG file format, you can import a graphic in as a vector graphic that appears as code. Cool. Using a static FXG image is great for icons or other static simple images, because its rendering is faster than an MXML graphic container.

Flex States

Instead of using AddChild and RemoveChild for changing states, you have includeIn=”" and excludeIn=”" attributes that go directly on components. What’s more, you can set various attributes of a component for the different states by using a dot notation. For instance, title.mystate=”Title”. This seems like a pretty drastic change.

With states, you have to use the OLD way with the 2006 namespace, and you have to use the NEW way with the 2009 namespace.

Skinning

Components all have separate skin files. This will allow you to create a custom skin for any component easily.

Common migration issues

Type selectors need namespaces now in your Flex CSS. For instance, if you’re styling a button, Flex doesn’t know if it is a Spark button or a Halo button. So you need to define the namespace in your stylesheet and update your selectors accordingly.

You must compile against Flash Player 10. This won’t be an issue if you use Flash Builder 4 with Flex 4.

Application.application should now be renamed to FlexGlobals.topLevelApplication. Just a direct rename.

RSLs are on by default.

The “Declarations” tag is a problem child. In Flex 4, anything that is not a display object or default property must be within the fx:Declarations tag. Even tags like RadioButtonGroup. Formatters, Effects, RPC stuff, Validators, etc. need to go in the Declarations.

“If Looks Could Kill.” The default theme is now Spark, which looks different than the old Halo theme. You can switch back to the Halo theme. To do so, turn on “Use Flex 3 compatibility mode” in the project properties, or go into the “Flex Theme” panel and change the theme (this is the preferred way).

If moving to Flex 4, try to use as many Spark components as you can. They should play nicely with MX components. You can intermix them together. Caveats: (1) The graphic primitives cannot go in an MX component, just wrap them with a group; (2) you cannot put MX components in Spark containers; (3) MX effects do not work on Spark graphic primitives; (4) MX navigators (ViewStack, Accordion, etc) should use NavigatorContent component.

Other things to watch out for:

• Spark components don’t support the Halo theme.
• Cannot create spark component based itemRenderers for MX List based components
• APIs between MX and Spark components are different (e.g. addChild vs. addElement)!
• When using MX and Spark components together, you may see a text difference since they are themed differently. There is a TLFText theme that can help with this.

So, migrating an app from Flex 3 to Flex 4 is a bit of a slippery slope. And even just beginning to use Flex 4 with current Flex 3 knowledge will require a bit of a slowdown as you undo some of those brain synapses to do things the new Flex 4 way. But these changes going forward are good for the Flex framework.

The key is to set up a cursor that will loop through the Data Provider for the datagrid.

Something like this:

That's all there is to it.

But I was clueless to these poor experiences since I hadn't tested these scenarios. Fortunately, my app was just released, and only to a beta crowd.

To test the absence of Flash Player, you can download a Flash Player Uninstaller and uninstall Flash Player. I'm not sure what the best way is to install and test an old version of the Flash Player; I just had a virtual machine that had an old version on it, so I used that because it was convenient. If you google for "download flash player 8", there are some non-Adobe links that appear to be valid links, but I did not try these.

Adobe has a Flash Player Detection and Installation support page that is helpful as well.

Before getting started, note how Microsoft and Adobe are taking two different approaches: Microsoft is trying to bring the .Net desktop development community to the web. Adobe is conversely trying to bring web developers to the desktop! (Kevin Lynch)

There are four main options for AIR local storage: Local Shared Objects, File System, Encrypted Local Store, and the embedded SQLite database. Shared Objects are available in the Flash Player as well; all of these options are obviously available in AIR. Note that the data size limitation for Shared Objects does not exist in the AIR runtime!

Performance considerations. Shared Objects read and write very quickly. File system access and encrypted local stores are typically be slow in writing. Embedded SQLite databases are typically the best combination of speed and random access of items. Greg highlighted the AIR_LocalStorage_Demo app created by Jason Williams that demonstrates the speeds of the four storage methods.

Local Shared Objects. You can serialize memory resident data structures. Great! However, it runs in synchronous mode.

Encrypted Local Store. Used to store sensitive data. The price is the slow write speeds.  Also runs in synchronous mode. All data is serialized using ByteArray.

File System. Obviously important for management of documents. Can run in sync and async mode. The File and FileStream objects work together to point to a file and read/write data. The File object helps remove you from the pain of dealing with Mac vs. Windows environments with properties like File.userDirectory, File.documents.Directory, File.desktopDirectory, etc. It also has methods for opening Open and Save dialog boxes native to the environment as well as copying/moving/deletion methods.

Embedded SQLite Database.  Nice thing about them is that they are self-contained in a single file and require no external software installation to begin using them (support is built into the AIR runtime). Even supports transactions. And the database supports large amounts of data: SQLite has a theoretical limit of over 2TB. Supports ANSI-SQL 92.

However, it's not a full-blown enterprise database server, obviously. So you lose things like stored procedures, enforcing data type constraints, foreign key constraints, and primary keys must be integers. It also isn't a multiuser environment.

Session evaluation. I am unhappy to say that I was disappointed with the session. It was high-level, the coverage of code samples (when they weren't passed over completely) consisted of merely reading the code back to us. I recommend viewing the recording if you have zero knowledge of data storage in Flex and AIR, as it would serve as a decent first-baby-step introduction for you.

So, what's the problem? In a nutshell, when you try to use the RemoteObject component in a Flex app to communicate with CFCs, the default installation of ColdFusion 8 and Flex Builder 3 will compile your app to communicate with the ColdFusion server over HTTP (http://yourserver.com/flex2gateway/), not over HTTPS (https://yourserver.com/flex2gateway/cfamfsecure), regardless of whether the SWF was loaded over HTTPS or not.

If your site exists in both HTTP and HTTPS, you may not even be aware this is happening. I wasn't aware of it while I was developing on my local machine. But our production server hosts its site only in HTTPS and the site on port 80 is a nearly empty site that redirects all requests to the SSL-protected version of the site. So this behavior broke my Flex app.

If your site exists only in SSL or sensitive data is being transmitted to and from the Flex app and the CFCs, you probably are trying to get RemoteObject to communicate over SSL.

Quick workarounds. If you have time and leniency to skirt the issue, you can avoid the RemoteObject/SSL issue. You can always use the HTTPService and WebService components instead of RemoteObject. But like most workarounds, this has its disadvantages and limits you from the benefit of using RemoteObject.

I imagine you also could set up a ColdFusion mapping to make the CFCs available on the HTTP site, but this solution is viable only if you really don't care about security, in which case you probably wouldn't have your site wrapped in SSL anyway.

The solution. What makes the solution tricky is that there are a few things that have to be configured properly, and there are some pitfalls along the way that can be misleading. The primary solution lies in some changes to the ColdFusion server's config files services-config.xml and remoting-config.xml. These both reside in {ColdFusion installation}\wwwroot\WEB-INF\flex\. For instance, on my Windows workstation, this is located at c:\ColdFusion8\wwwroot\WEB-INF\flex\.

1. Add the secure channel to remoting-config.xml. ColdFusion 8 already has a channel in its configuration for RemoteObject over SSL--it is called "my-cfamf-secure"--it just isn't configured to be used. So you have to add the "my-cfamf-secure" channel to remoting-config.xml. To do this, add <channel ref="my-cfamf-secure" /> to the <default-channels> node and the <channels> node for the "ColdFusion" destination.

In other words, your new remoting-config.xml file should look like this:

This brings me to the first pitfall to watch out for. Be sure to list <channel ref="my-cfamf-secure" /> ahead of <channel ref="my-cfamf" /> so that ColdFusion will try the secure channel first.

2. Add a property to make IE happy. At this point, your configuration will be adequate for Firefox. However, IE still seems to get tripped up and tries to access the insecure channel. To fix this, just add <add-no-cache-headers>false</add-no-cache-headers> to the <properties> node of the <channel-definition> nodes for "my-cfamf" and "my-cfamf-secure" in services-config.xml.

I won't display the entire services-config.xml file here, but your "my-cfamf" channel definition will now look like this:

And the "my-cfamf-secure" channel definition:

Some more pitfalls to consider. These can be really misleading, making you think your changes aren't working.

A. Flex Builder incorporates these settings into your app when it compiles the SWF. Go to your Flex project's properties, under "Flex Compiler", and you'll see a reference to your services-config.xml file. If your SWF is compiled on a workstation that hasn't had these changes, it will not work on your server, even if you did change your server's config files. So be sure that your local installation of ColdFusion has its services-config.xml and remoting-config.xml files updated just like your production server.

B. On a related note, be sure to recompile an app if you've compiled it before making these config changes. You can recompile in Flex Builder by going to Project > Clean. That option will ensure that you have a clean, recompiled SWF.

C. If your SWF file is actually served on port 80, it will not be allowed to communicate over the secure channel unless you tell it that it is permissible to do so by setting up a crossdomain.xml file. Check out Shannon Whitley's post SSL, crossing domains, and Flex to read a bit on that.

Tools for the job. With the right tools, you can test all of these things out on your own. For instance, Firebug and Fiddler are great tools for Firefox and IE respectively that clearly show your Flex app's behavior, and whether it is attempting to access the secure or insecure channel. They also show the app attempting to access a crossdomain.xml file when the SWF file was loading over HTTP, because it's first attempt is to make a cross-domain connection to the secure HTTPS channel.

The great thing about this configuration is that your SWFs will use the secure channel when they can, but silently fail over to the insecure channel. So your development workstation doesn't have to use SSL, but your compiled apps will utilize it when you move them to your production server. This is cleaner than setting up a separate "Destination" in remoting-config.xml, or other solutions that require changes to your app's code. Alas, I am still green in the Flex universe and don't claim anything different. Nevertheless, this solution is working perfectly for me and I hope it proves useful for you.

Many developers were frustrated--and many web developers had our curiosities pleasantly piqued--when Apple initially announced that "software" would be available for the iPhone in the form of Ajax web applications. Naturally, many of the disappointed folks were irritated because the web platform is something that they're entirely unfamiliar with, probably having backgrounds in Objective C or something similar; probably a minority were disappointed because their target application legitimately could not be powered by HTML and Ajax.

That said, it is indeed a very thought-provoking concept: Using web technology as your application environment. As most web developers will attest to, there honestly isn't that much that a typical application does that cannot be accomplished with web technology. With the advent of Ajax frameworks, applications built with web technology can have very similar responsiveness and dynamics of a "classic" application. Especially when you remove the burden of cross-browser compatibility, in the iPhone's case.

But with the iPhone/iPod Touch scenario, it is irritating that the application has to reside in Safari and has to be loaded off the web. It almost feels as if Apple was trying to push something that wasn't...quite...ready. Something like AIR!

AIR accomplishes everything that Apple was suggesting for the iPhone environment, but for the desktop. Use web technology, but write a "compiled", stand-alone application that really doesn't even have to use the web. Use HTML. Use Ajax. Use Flex and Flash. Have a nice encapsulated application on your desktop. Especially when you throw the Flash technology into the platform, it is now a very capable environment for a large variety of applications, without being constrained to the browser. Wouldn't it be great if that same cross-platform environment, AIR, worked on the iPhone as well?

Oops, Flash technology isn't currently supported by the iPhone. That is actually another source of contention. And the AIR environment does lose some of its punch without Flash and Flex, even though its HTML/Ajax implementation can do a very decent job with most typical applications.

Steve Jobs has made it clear that he likes the idea of web technology powering iPhone apps. Now, consider some of the facts. Apple announces the iPhone SDK will be released in February, and then fails to deliver. Meanwhile, Flash still isn't found on the iPhone, and Adobe "invents the wheel" by getting web technology to drive native apps through its work with AIR. Is there a common theme with these events? Perhaps something like: Are Apple and Adobe working together to get the much-needed Flash technology onto the iPhone and, subsequently, releasing an SDK that uses AIR technology, with hooks into the iPhone system just like AIR currently has hooks into the Linux, Windows, and Mac OS X desktop operating systems?

It wouldn't be the first time Apple has had to wait for its partners, or take the heat for them. For instance, Apple has clearly been taking a lot of heat for many factors of the iPhone that are clearly not in Apple's interest, but in AT&T's.

And this scenario would fit the circumstances around Adobe's development of AIR. Adobe has been working on AIR since well before the iPhone was released, but AIR wasn't officially released until February 25, 2008. Even if Apple and Adobe were working closely together, there just hasn't been enough time for AIR to get released and hooks to be developed to provide iPhone-specific functionality in AIR. Adobe has understandably concerned itself with its own business first. With that done, attention can turn to Apple to support them in concluding their own business.

Of course, this prediction is a reflection of my own desires as much as it fits the circumstances. As a developer that uses Adobe technology including Flex and AIR, and an Apple enthusiast for more than 20 years, I would love to see things happen this way. Undoubtedly we will have a clearer idea of Apple's iPhone development roadmap after this Thursday.

As if the thought of an "iPhone AIR" isn't confusing enough.

History lesson. Flex 1.0 introduced MXML. Originally built to be a server-based compiler. Flex 2.0 fine-tuned the product. ActionScript 3 was introduced, the Eclipse-based IDE was developed, and the server-side component was renamed Flex Data Services. That server-side product continued development and was renamed eventually to LiveCycle Data Services. Finally, a free portion was released as BlazeDS. So, its heart and heritage is in the development of Flex.

So what is BlazeDS? The part that lets your Flash/Flex app have remoting and messaging services via web services, remote objects, data push, etc.

Remoting. Used to be Flash Remoting. Allows mx:RemoteObject tag be used to make RPC calls to the server. Allows you to use CFCs and ActionScript or MXML together! Works with Java classes too, but obviously it is very nicely integrated with ColdFusion. This is the most familiar purpose for this kind of tool. But what else can BlazeDS do?

Messaging. Publish and Subscribe functionality becomes trivial. We can have real-time pushes over the web. What exactly does this mean? Your Flash/Flex apps can push data from one client to the next without refreshes or polling the server.

These services use AMF (Action Messaging Format). It is fast and small: Rather than being verbose text, it is a compact binary protocol. Not that you would ever have to know that, because it just happens behind the scenes. And its specs have been released, which means it can be supported by open source and third party developers.

So why would you still get LCDS? Well, you get certified builds with warranty coverage and support. You're paying for Adobe to back the product. There will even be an LCDS "Community Edition" that will basically be BlazeDS with this support. Somewhat reminiscent to Red Hat vs. CentOS: Why get Red Hat when CentOS is everything Red Hat is? Because Red Hat has official support for its product. So Adobe is making the technology freely available, and giving you the option to pay for support and official builds and bug fixes.

LCDS "Enterprise Edition" is still the mother of data services. This version adds the data management capability of data services.

The installation of ColdFusion 8 gives you the free express edition of LCDS. But this is a single CPU license. If it doesn't meet your needs, you can configure BlazeDS for ColdFusion 8. But to do this, you WILL have to remove the LCDS Express Edition that installed with CF8. Now, if you're just using Flash Remoting, there isn't any burning need to go to BlazeDS with CF8. However, the messaging features have no CPU restrictions with BlazeDS, so if you are using the messaging features, you may want to go with BlazeDS.

What do you use with BlazeDS vs. LCDS? LCDS has the data management features: Real-time data updates, conflict detection, caching, paging, more! RTMP channels: Direct socket connection to server, instead of the more resource-expensive HTTP. Scalability is also better with LCDS.

Tom indicated that Flex and BlazeDS will not be standing still. He certainly implied that Silverlight is in Adobe's sights by indicating that it is "nipping at [Flex's] heels", suggesting that the AIR, Flex, and BlazeDS technologies will be progressing in development at a rapid pace by Adobe.

Tom explained BlazeDS and LCDS very clearly, albeit at a quick pace at first. My development rarely calls for the messaging features that would especially drive me to BlazeDS, but even so, it was beneficial to understand what BlazeDS is and it is good to know even when a product is not needed in your development arsenal, as in my case. For me, I will be using remoting only, so will stick with LCDS Express that comes with CF8.

Thanks, Tom.

What ultimately prompted my thoughts was the article Web 2.0 Needs Adobe by Tom Yager. His discussion is very flattering for Adobe, although ColdFusion isn't mentioned anywhere. Neither is it mentioned in Cringley's equally flattering article An AIR of Invisibility. There's a reason for this. They're focusing on the user interface of apps, which is really what defines the perception of how responsive and powerful an app can be. Fretting about ColdFusion getting the back seat is like fretting that your favorite athlete wasn't nominated for an Oscar; it wasn't really up for consideration.

So, user interface. Now that's something to fret about. Many of us don't like to think about the UI, and that has to change! User interface has always been important when users form their impression of an app, and that high priority is applying more heavily to web apps as they begin to vie for user acceptance with their heavier desktop brethren.

Most ColdFusion developers are using HTML for their user interface. An industry migration will hopefully migrate that median toward AJAX-enhanced HTML or Flex interfaces for web apps, and of course AIR for desktop apps. ColdFusion won't be going anywhere, as our internet connectivity is always going to need a server-side component.

So how are we to react to these articles' evaluations of AJAX and Flex? In a way, they are depicting JavaScript (and thus AJAX) as a dinosaur with wings. It is powerful, it got a shot in the arm with the popularity of AJAX, and it can do amazing things. But it's still a "dinosaur". It is old technology trying to keep up. Enter Flash and Flex. The new kids on the block. They're more modern--but they've had time to mature--and they just out-perform AJAX in what they can accomplish. Now tack on thoughts about how much AJAX functionality Adobe has put into CF8. What's the point if AJAX is inferior to Flex? What does it all mean?

It's a big internet out there. Various scenarios call for various solutions! Whereas it is a good idea for us as ColdFusion application developers to learn Flex and start using it when UI needs call for it, the ultimate point is that we start improving our UIs from plain HTML. Start putting more effort into the user interface. We've had it easy in the past when simpler, less sophisticated interfaces were accepted on the web, and that time is coming to an end as the web pushes forward as a viable application platform.

Is it urgent that we start learning Flex? I feel that AJAX and Flex will be sharing the web application space for a long time. Yes, Flex and Flash might be Adobe's ticket for bringing web apps to the next level, but their commitment to AJAX is very clear. That is evident in the AJAX support in CF8 and AIR. Learn Flex if you can. If it's just too much for you to handle right now, AJAX is a fine step--more palatable and familiar for HTML developers--that will let you focus on the more important point: Improving your app's user interface.

With it, using AS3 and Flash Remoting, you can do stuff like invoke CFC methods from within ActionScript!  No Flex server is involved.

Messaging. Publish and subscribe. I say hello and everyone will listen to me. Someone says goodbye and I hear, and know not to talk to them anymore. ColdFusion can be both a Producer and a Consumer. Publish with sendGatewayMessage() and subscribe with an event gateway CFC.

New in CF8? Faster. Now uses Java API instead of that RMI.  Starting with CF8, it is included right in the CF installer. An express version comes right with CF8.

Not many notes on this, I wasn't following too closely since we won't be getting LCDS, at least not until I'm more heavy into Flex.

I didn't take any notes during Rob's class, as we spent practically the entire class scouring through FLEX examples. I did take notes during Peter's class during the discourse sections of his class.

FLEX Intensive for ColdFusion Developers

I have two reasons for learning FLEX: (1) I am interested in developing AIR applications, and I'd like to do some of the more advanced functionality, which requires FLEX. (2) After learning the basics of FLEX, I want to try to use FLEX for some enhanced form functionality!

I think I'd only want to write full-fledged FLEX apps when writing AIR apps. To do this, Rob recommended the official Cairngorm microarchitecture, although Model Glue: FLEX is now a new option to look into as well. He also recommended using Cairngen to get things set up and started with Cairngorm.

Rob usually does include the compiled FLEX SWFs in his Subversion repository. He will have the FLEX source in one directory outside of the web directory, and have the binary output directory be the assets directory within the web directory. This way, the compiled FLEX is ready to be used within the web app, and everything can just be committed to the repository.

Rob recommends using SWFObject for deploying the SWFs.

Finally, he recommended the FLEX-AJAX Bridge.

Practical Code Generation: By Example

Peter Bell's class was amazing. Even if you decide to use frameworks, you can automate work or application generation by using code generation. Below are my notes from his class.

Active generation (can regenerate as requirements change, and custom code is in separate files) is better, although passive generation (can generate once, but requires tweaking, and cannot regenerate) is faster to implement.

Methods for creating the code.

Concatenation: Code stored in a variable. <cfset ScriptHTML="<cfquery>..</cfquery>">. Good for when there’s variables, looping, etc. When there is a lot of specialized processing.

Templating: Much better. Template-based approach is easier to read and takes up less space. Good for mainly fixed code. Simple models. And it’s an approach we are familiar. ColdFusion itself is a manner of building HTML templates that get modified by the code.

Anatomy of a Generator.

• Metadata (List of fields, etc). Could be in database, XML, etc.

• Template.
• Iterator. We immediately think, “For each business object, do…”
• Orchestrator.

Metadata.

Use ColdFusion to build structs. Use XML. Or even flat text in a particular format. Any are fine.

Template.

XSL, CF Template. We will use CF Template because its readability is so much better than XSL.

Iterator.

Generate n files. One DAO per business object. One template per screen. Need filter support.

Orchestrator.

Generate m collections of n files. Tell it what metadata to use with what template, iterating how many times, and how to generate the filenames.

Extending Generated Code.

Need to mix the custom modifications with the standard generated code.

Protected blocks. Mark where generated code exists with a special string, and generator will not touch code inside custom blocks. Can actually be harder to write a generator using this method too. So this method is out of favor.

Inheritance. Just generate the standard CFCs, and you can have custom decorators that inherit the standard CFCs.

Events. Have custom code that looks for events, and when particular events are thrown by the standard code, the custom code method would generate.

Mixins. You basically put a right into the standard code so that the custom code can be inserted right into the execution stream. Of course, this introduces lots of conflicts since you’re sharing the time and space with all of your standard code.

Aspect Oriented Programming (AOP). When someone calls this method, before, after, or during that, call some custom code.

Frameworks vs. Code Generation

Remember when there was the initial conflict between compiled vs. interpreted languages? Same consideration for frameworks vs. code generation. Not either/or. Typically there will be a combination of generated code vs. frameworks you use. Intellectual property and performance concerns may be there. You may not want to give away an entire framework that will build something quickly that the clients can change themselves. So, this may cause you to choose code generation.

Getting Started

http://cftemplate.riaforge.org
http://cfgen.riaforge.org
http://www.pbell.com

Also check out opensource projects ColdSpring, LightWire, IBO.

Additional Notes During Walkthroughs

If you want to automagically generate IDs, titles, etc. for all aspects of the database and CFC, decouple it from the primary code generation. This way, you can generate stuff with almost no work, but yet it is still customizable because you just tweak the generated metadata for the code generation!

Design Patterns

Model-View-Controller. Business logic in the model. The meat of your application. View is the presentation. Perhaps some HTML or AJAX or Flex that displays it. Controller glues the two together, getting something from the view to the model.

Be careful against putting things in the wrong area. Most notably, beware logic in the controller! If just a web app, you may not notice, but when implementing AJAX or other connectivity, this can cause a problem.

Model consists of:

• Bean. Basic business object. Gets, sets, validation.
• Service Class / Manager. Used to get beans, in different ways. GetByFilter(), GetByProperty(), DeleteByFilter(), DeleteByProperty(), Save(), New().
• Data Access Object / Gateway.

CFM page -- Service, which may gen bean -- DAO -- DB.

Generic getters and setters can be handy for dynamic references. Easier for code generation too. Use in conjunction with a GettablePropertyList and SettablePropertyList for controlling access. Can have custom processing too by checking for the custom getter or setter and calling that with an Evaluate().

Typical IBO: get(), set(), access(), mutate(), loadStruct(), loadQuery(), first(), last(), next(), reset()

Remember, even if you just use a code generator to generate forms, or ColdSpring config files, or various other repetitive items, do it! If there is a framework that will meet your needs well enough, just go with that, but you can still help implement it with code generation.

Be careful--there is so much data overlap between the database specs and the CFCs and the forms and whatnot, that before you know it, you’ll be writing code generation for the whole app.

When doing the code generation, you then should use inheritance for the custom code. Develop your service so that it will look to see if the custom CFC exists, and if not, it just sends back the base CFC. You could autogenerate an empty CFC, but then you have to look inside the empty file to see if you have any customization. It is more apparent if the custom CFC doesn’t even exist!

Conclusion

These were a couple great classes. A lot to think about.