Leveraging ColdFusion With AIR
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.
October 2nd, 2007 at 6:27 pm
Hi,
I really think this is almost a non-article. At what particular point did you actually think CF web apps would actually work within AIR in any other way? It is a server technology. Not a client side technology.
You will most likely be writing Flex AIR apps hooked up to webservices provided by a CF back end.
Adam
October 2nd, 2007 at 6:54 pm
@Adam, I believe he was summarizing a MAX session.
October 2nd, 2007 at 7:21 pm
Brian, you’re right. Thanks. Adam, sorry, I’ll try to indicate that my posts are session notes in the future.
At the sneak peaks session right now! Posting this comment from my iPod touch!
October 8th, 2007 at 6:26 pm
Thanks Josh for this summary. I was hoping that Rupesh Kumar was going to post something on his blog and he has yet to do so. I appreciate the notes summary, my notes were a bit more chaotic.
October 13th, 2008 at 3:29 pm
I am a CF Developer for almost 10 years now. I really liked the idea of Adobe AIR and hence use my existing knowledge to develop desktop applications.
Although my knowledge in JavaScript is quite good – I find it extremly hard and time consuming to use JavaScript to fetch some data from a database, compared to the of ColdFusion.
Really, the idea that Josh mentioned (i.e. wrapping a CF Application within a frameset) sounds cool for me! Especially with CF8 and the whole EXTJS library that is included!
Advantage: Quick development of almost anything! ColdFusion can be used for Desktop Programming as well and where more desktop programming is required (i.e. quering the local filesystem) you can use AIR with JavaScript.
Disadvantage: You cannot built commercial applications, except if your customers will have a ColdFusion version running on their PC. The good news is that you can install an application by installing the free (developer) edition of ColdFusion server. Also, the AIR libraries need to be installed too
If only Adobe could include a CFML engine on future AIR release…..
)))))
October 19th, 2008 at 7:01 pm
@CF_George: I must give credit where credit is due; this post is just my notes for a session I attended at either MAX or CFUnited (can’t remember which?).
Putting the ColdFusion pages in a frameset is a solution that works, but not recommended for running ColdFusion on the local user’s PC. The idea is that the frameset in your AIR app points to a publicly accessible website.
This is one step simpler, albeit more kludgy, than using CF simply for storing the data, but actually setting up CFCs to serve as webservices that your AIR app will talk to. This is where my development usually sits… Users have a desktop app, but it requires a net connection to communicate with a CF server for storing/retrieving data.
The final step of fine-tuning is to make your app download/upload data to the server when it is online so that it can still operate with a local copy of the data when it loses a net connection. This is most graceful to the users’ perspective, but requires quite a bit more work.
I agree with you, and hope that Adobe makes local database access easier (more like CF) in future releases of AIR.