The following are notes from the XML 101 class at Adobe MAX 2007. I’m skipping over the extremely basic XML principles and covering the more interesting stuff.

When use XML nodes over attributes? Attributes are good for set, simple values. If you have complex values, multiples of a particular entry, or you want more extensibility, use nodes for XML.

The presenter demonstrated using DTDs over XML Schemas. The DTDs use a very specific grammar that is not even XML-ish. It’s kind of yesterday’s XML descriptor. Nowadays, better to use XML Schemas, which are actually XML defining XML. Both are ugly in my opinion, and XML Schemas are more verbose (as XML usually is), but you might as well go with the latest, most accepted convention, which is the XML Schema approach.

By using DTDs and XML Schemas, apps can be cognizant of the structure of your XML language. Even from a developer’s viewpoint, this can be useful when editing XML within an IDE.

The real fun part is formatting the XML with XSL (eXtensible Stylesheet Language). Supports loops, conditional logic, and other processing. Think of it as CSS on steroids, for XML. With XSL, you can transform XML to HTML, or PDF, or other fun stuff.

XPath is the heart of XSL processing. Allows you to traverse the XML document and find exactly what you’re looking for, whether it’s a particular node or looping over a group of items (xsl:for-each).

You CAN send the XML and XSL to the client and have the transformation be done client-side. All modern browsers include the XML/XSL engine. But generally it is wiser to do the transformation on the server side.

In my opinion, this approach lowers the value of XSL, because I can just as easily write some CF that will act on the XML. Yeah, I can write numerous XSLs for different presentations (text-only, XHTML, PDF, etc), but I’d have to do the effort of writing different XSL docs for that, when I could just as easily write different CF processors that accomplish the same thing. Unless you are working with a huge number of documents of varying types, XSL may not provide a large enough of an advantage for a language like CF that so easily manipulates XML.

The final step is grabbing XML with Ajax (such as Spry) that will populate document spaces (tables, divs, etc) with the XML data very easily as well. Again, this approach is similar to the CF approach, but with a more JavaScript-heavy slant.

AIR does not have a CFML engine. ColdFusion cannot be packaged within AIR apps. Traditionally, we use CF to generate the UI. However, in AIR, typically the UI is pre-designed and packaged. How does ColdFusion fit in, then?

Use ColdFusion apps directly, use ColdFusion as the data provider, or use ColdFusion as the data provider and as a UI provider.

To use a CF web app directly, just wrap it in a frameset. This is so kludgy, I can hardly stand it. But it will work to put your web app in a desktop app at some basic level. I suppose it could be handy since it hides the URL, it can make a more kiosk-ish look. Could also be useful if part of your app is a normal app, but part of it should mimic the web app exactly and you don’t want to rewrite anything.

Better to use CF as a data provider.  ColdFusion is best at connecting with other systems, connecting to remote DBs, etc. Then communicate with web services, XML, flash remoting, JSON.  There is nothing new here, at this point, you just build typical connectivity that AJAX or Flash would use.

Flash remoting would probably be the best when using Flex. Provides a handy proxy-like access to your CFC.  Web services can also be done very easily with Flex.

Now, how about HTML/JavaScript (AJAX) in AIR? CFAjaxProxy, XMLHttpRequest, or plain HTTP (CF returns the data in XML, JSON, or text).

CFAjaxProxy. Makes a CFC available inside AIR app. Creates a JS proxy for a CF component. So on the CF side, you use cfajaxproxy, point it to a CFC, and instantiate the CFC in JS. Now, some initialization code is required. It is generated by the cfajaxproxy tag. So just copy the literal HTML/JavaScript generated by cfajaxproxy, and drop that into your HTML for AIR (just change the URL to the CFC to be the absolute URL; cfajaxproxy will write it as a relative URL).

It wouldn’t hurt to just write some basic AJAX code on the web, using cfajaxproxy, and then copy that to your AIR HTML.

Now what about taking your apps offline? Well, you’ll need to identify what is going to work offline, and store offline data (either to the filesystem or to a local database). Decide how the app will go offline: Modal (distinct offline/online mode, user driven, easiest to implement), or modeless (seamless offline/online mode, most of data is stored locally, better user experience but more work for the developer). Then, synchronization strategy: Manual sync, background client-driven sync, or server-driven sync.

Synchronization and online/offline management can be improved. They will describe more at the sneak peak session. Code samples will be at his website, http://coldfused.blogspot.com.

Why care about caching data on the client? There are 3 types of apps out there: Thin Client (HTML/JavaScript to web browser), Thick Client (Word, Excel, etc), Smart Client (RIA, a hybrid between the thick and the thin). Thin client and smart client both allow ease of deployment, but offline capability and access to hardware resources is problematic for the thin client.

AIR allows web technology to be deployed directly to the desktop.  Flex, flash, PDF, HTML, JavaScript, CSS, Ajax.  Always starts with a root document (HTML or SWF). HTML may contain PDF or SWF. Both have renderer, VM, and DOM.  Code between the VMs can interoperate.  All can be display in native OS chrome. And you can persist data locally (hence this preso!).

Storage models: Local shared objects, encrypted local store, file system, embedded SQL database.

Local shared objects. There are in package flash.net.*.  Used to serialize memory resident data structures. Runs in synchronous mode. This is a monolithic storage model. So it is fine for writing huge amounts of data, but when going to retrieve a single entry out of thousands, can take a proportionately long time.

Encrypted local store. In package flash.filesystem.*. Used to store sensitive data. Runs in synchronous mode also. All data is serialized using ByteArray. So it’s like blob storage with keys. A ByteArray is like an in-memory stream of information. So you take an array, put it in a ByteArray, then add the ByteArray to the encrypted local store. This encrypted local store is just this space that is available to you based on the application and user.  And it is faster at accessing the record you want. But the point isn’t that it’s faster at accessing records; the point is that it is doing security to make sure no one can read it without authorization.

File system. In package flash.filesystem.*. Provides random access to file system data. Can be asynchronous or synchronous. Two main components: File and FileStream. File represents a path to a particular file or directory. Completely OS-independent. FileStream does the actual work. Handles binary, object, text data.

Path handling: nativePath(), canonicalize(), resolvePath().

Cataloging: userDirectory(), desktopDirectory(), documentsDirectory(), applicationResourceDirectory(), applicationStorageDirectory(). File info (size, createDate, etc). copyTo(), moveTo(), etc. upload(), download(), send(), etc.  browse(), browseForDirectory(), etc.

FileStream implements the IDataInput/IDataOutput APIs. Can put binary data in — readBytes(), writeBytes(), readInt(), writeInt(), readDouble, writeDouble, etc.  Can do AMF3/AMF0 object serialization — readObject(), writeObject().

Embedded SQL Database.  Self-contained factor is nice. You have no external dependencies; it will work the same on any OS. Each database is stored completely within a single file. Zero setup. No configuration or administration required. It just starts working.  No server process required, no need for an administrator to create the database and user accounts. Handles transactions! Has a large capacity: Theoretical limit of over 2TB.

Package is in flash.data.*. Can be asynchronous and synchronous.  Uses SQLConnection and SQLStatement.

SQLConnection. Establishes connection state, configuration, transactions, schema access. In async mode, also creates its own background thread. So you can create five SQLConnections to run five database operations simultaneously.

SQLStatement. Does CRUD operations. Does parameters, paging, and custom result row data types.

The database functionality is VERY fast. Can work with thousands–millions–of records in less than 1 second. Data reads are even faster.

SQLConnection: open(), attach(). The attach() will allow you to run queries on tables across multiple databases. Comes in handy during certain circumstances. Handled not too unlike SQL Server, when you are referencing an external database in your SQL statements.

SQLStatement.getResult() — Returns a SQLResult object.

SQLResult: data() returns an array of objects that contain each row of the result. complete() indicates if you pulled the whole result set. lastInsertRowID() is self-explanatory. rowsAffected() is also self-explanatory.

Note! Putting data on disk via the database can be slow sometimes. Recognize that it is a 6-step process: (1) Acquire shared lock on the database. (2) Acquire a RESERVED lock on the database. (3) In-memory rollback journal is updated. (4) Contents of rollback journal are physically written to disk. (5) Acquire an EXCLUSIVE lock to the database. (6) Write all modifications for the DB to the disk.

At this rate, you’re probably only going to get 5-6 database transactions per second.  Maybe as many as 20 on a high-end box. So the key is to put MANY database operations all in a single transaction.

Transactions. SQLConnection manages the transaction. Use SQLConnection.begin() to start the transaction. Then, commit() and rollback() work as expected.

Storage classes. There are numbers (int/real), text, and blobs.

Affinity. Declaring a data type on a column determines the column’s affinity. You’re saying, “I want this field to be stored like this.” However, if you send a string to a field that should be a number, it won’t throw an error, it will just put it in there as a string.  Supports ActionScript affinities of boolean, date, int. Next beta should support XML, XMLList, Object, etc.  But currently, you can put arrays or objects in with blob, which will then treat it like a ByteArray.

Introspection. Access to the table/view, column, index, and trigger information, including the SQL used to create the entity. But you can do selective loading, i.e. I want to see the tables in this database. Just use SQLConnection.loadSchema(). Will return a SQLSchemaResult that has tables, views, triggers, and indexes. These are all arrays of objects with the associated values.

Window API. Lightweight windows are nice because they won’t appear in the taskbar/dock.  Utility windows don’t even have title bars and are nice for toolbars or similar things. You can have transparent windows so that the only content you’ll see is the Flex/HTML content you put in there.

Transparent windows require that you build your own functionality for window handling: Closing, minimizing, moving, resizing, etc. Now, when you use custom chrome, you can use Scale-9 in Flash/Flex to make it really easy to handle how resizing of the graphic works. You can do this with the <mx:canvas> tags in Flex.

HTML Control. WebKit is entirely integrated into the Flash Rendering Pipeline. Using the bridge, you can use functionality in either JavaScript or ActionScript and use it in the other environment: AS called within JavaScript; JavaScript called within AS.

File I/O. Full read/write access within the access provided the user running the OS. Have asynchronous and synchronous versions of the API. So quick and small file access can be done in a synchronous manner quickly, and longer access can be done asynchronously to maintain a quality user experience. Use standard native file dialogs: Save, select, select multiple, directory.

File I/O can save not just text/binary stuff, but you can read/write serialized AS objects. So, you can create an AS object with the info you need, then very rapidly write it out and have it very easy to read back in as that object.  Just use the writeObject() method of the filestream! Similarly, just use loadObject() when reading.  To make this work, you will need to add a tad of metadata to the object to make it work. Another caveat, the data will not be human-readable. But if human-readability is not important, this is much more rapid for writing a lot of data than it would be to save in some text or XML format and needing methods to write out and read back in the data.

Another solution could be to write this kind of data to the database via the database API. But sometimes that may be overkill, plus this can write files anywhere.

Database. A fully-embedded SQLite database engine. You’re accessing a local database. This is not for accessing remote databases. To do that, you’ll want a webservice that provides access to that database.  This database support is great for providing online/offline support. You can sync the information locally and then just utilize the local version.

One note: Every database function will be a separate transaction. If you have hundreds/thousands of database functions to perform, wrap them into one transaction so that the filesystem can do the file transaction more efficiently. In his sample, writing 1,000 database records took 2.3 seconds with no transactions; it took 0.1 second with transactions.

When handling database connectivity, you will: (a) Point to the database file. (b) If it doesn’t exist, do the code to create the database. (c) Do your database statements.