I attended Rob Gonda’s “FLEX Intensive for ColdFusion Developers” class on Monday and Peter Bell’s “Practical Code Generation: By Example” class on Tuesday.

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.