The following are my notes during the Adobe AIR Local Data Storage Options webinar that was presented during Adobe Developer Week. It was presented by Greg Hamer and the slides and demo code are already online.

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.

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.

These are notes for a presentation on Savvy, the content management system, by Joshua Cyr.

For setup, there is a cfm page that has numerous CFSETs that you have to set. After that, everything is basically good to go. It will create the database in the DSN you provide it, by simply running an install script by calling a cfm page.

First thing you’ll have to do when you login: Set up some templates for your site. In CFEclipse, he took a normal HTML page with content, and just started editing Savvy tags. He replaced the <title> with a header object, some menu navigation with a nav object, basic content with a content object. What about when you alter a template? There is an option to rebuild pages (or entire site) for when a template is changed.

He showed that an object can be shared. This way, anytime an object with that name appears on any page, changes to that object will be reflected on all of the pages.

Creating pages and directories, actual physical files and directories are indeed saved. This is handy for apps that do traffic analysis. Sometimes they sputter on pages that have a front controller for pages (index.cfm?page=MyPage).

When you create a page, you then can view each content area in the new page. Just click on it and you can edit that particular content area. The editing mechanism is pretty typical: A WYSIWYG editor, decent picture management. You can adjust settings so that the WYSIWYG editor will look exactly like you want it. Handling links is pretty simple: Can pull up a screen similar to picking a picture, except for pages. When you start typing a page name, it has auto-suggest to help. Note that the link management is very basic: It helps you create a hard link in the content, and nothing is done to warn you if you will break links when you change a page’s name or location (or delete it).

When it comes time to publish, you can publish an object at a time, or the whole page. Publishing can be scheduled, and expiration is available as well. Additionally, it supports workflow where the user will not have publishing rights, so instead he can request publishing, and then a person with that permission will do the publishing. Savvy does not have sophisticated workflow management, however. It keeps the process simplified. History of items is recorded and can be viewed. History by object/page or by user.

When managing users, you not only can supply exact permissions of what a user can do, but also can do groups that users belong to. Then perms are assigned based on their group.

Now, when you have CF in you template page, it doesn’t work like you’d expect, when a new page is created from a template, it will effectively paste in the results of your CF, not actually render the CF on the page. Thus, welcome to their custom code object. It effectively acts like a CFINCLUDE for your pages.

Savvy plays nice with other CF applications. He did not demo or speak on this any further, though.

Thanks, Joshua.

These are notes from the Design Patterns and ColdFusion presentation by Sean Corfield on 12/13/07.

Design patterns are basically common solutions to recurring problems. Using a pattern provides a common vocabulary between developers. If you say, “I’m using a Remote Facade”, someone else will know what you’re talking about without any further explanation.

What makes up a pattern? (a) A name, to provide a common vocabulary between developers. (b) A recurring problem; typically there are “forces”, or circumstances in the coding situation, that will lead you to use the pattern. (c) The solution, or template for solving the problem. Note that a pattern doesn’t have an exact, proper way to be executed. It is indeed just a guide, or template. (d) Consequences: Every pattern has its pros and cons.

Common Problems and Design Patterns

1. Problem: Duplicate site content at top and bottom of site.
   Pattern Name: Composite View
   Solution: Include a header and footer that has this duplicated content.
2. Problem: Need an instance of an object that is accessible everywhere in an application.
   Pattern Name: Singleton
   Solution: Create it at application startup and put it in application scope.
   Trade offs: Initialization is in one place (+). Easy access to objects app-wide (+). But now your code is very dependent on that application scope, which breaks encapsulation (-).
3. Problem: Several components make up a particular functionality, but you don’t want to expose all of that complexity to the calling code, especially in case I want to change how I implement it.
   Pattern Name: Facade
   Solution: Create a new component that has a nice, simple, high-level API. Client code calls it, and it calls all the complex components under the hood.
   Trade offs: App code no longer needs to no about all of the complex internals (+). However, there will be redundancy of methods between the API and the underlying code, which is more maintenance and more coding (-).
4. Problem: I need some standardized code that runs on every request of the application, perhaps security checks.
   Pattern Name: Front Controller
   Solution: Make all requests go through a common piece of code, and have that code apply the logic before/after processing the actual request. i.e. index.cfm?page=myaction. Everything routes through index.cfm.
   Trade offs: Full control over every request; can easily add add’l functionality (+). All URLs look similar (+/-). The control page (index.cfm) can get complicated (-).

Recognize that patterns are NOT code. Any example code for a pattern is just that: An example. Design patterns can apply to any language and typically can be used in the design phase of an app. Some patterns are language-specific. Do patterns have an object-oriented bias? Well, yes. Most design patterns are focused on OO design. But design patterns in general do not have to be OO-specific. It just tends to be OO people who are considering design patterns.

Ruby Patterns for Consideration

1. Active Record pattern for managing persistence of objects. An object knows how to save/get itself with a database.
2. Dynamic finder methods. By virtue of the method name, the functionality can be figured out. This is done with a method that runs when the called method doesn’t exist (”method_missing”). That method can than act on the method that was called based on its name. ColdFusion can do this with the onMissingMethod() method of a CFC.

Patterns and interfaces. Interfaces are not needed but are useful as a descriptive tool in explaining pattern implementations. ColdFusion 8 introduced <cfinterface>. Alternatively, you could use duck typing.

Design Patterns from Gang of Four

• Creational Patterns
  • Abstract Factory, Builder, Factory Method, Prototype, Singleton
• Structural Patterns
  • Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
• Behavioral Patterns
  • Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

To learn patterns, you can observe frameworks, which often implement multiple patterns: Front Controller, MVC, Identity Maps, Context Objects, etc.

Thanks for the great presentation, Sean.