These are notes from the presentation by Tom Jordahl about BlazeDS.

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.

The ColdFusion community has been paying attention to IT journalism lately, for better or worse, and for good reason. Our environment is especially in a state of flux; many of us may had been concerned about the future of ColdFusion given Adobe’s acquisition of Macromedia, but those fears were allayed, especially now with Adobe making it so clear that they have invested respectable time and resources into improving ColdFusion with CF8. But the results of the acquisition are only just beginning to emerge. And as Adobe’s strategy becomes clearer, it is very evident that they are putting arguably more resources into other technology like Flash and Flex.

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.

LiveCycle Data Services used to be separate from CF. Now they are together, so you don’t have to configure the RMI to have them talk to each other.

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