Raymond Camden's Blog

Adobe eSeminar on ColdFusion and Monitoring

Wed, 08 Feb 2012 10:41:00 -0500

(Sorry for the somewhat simple blog posts this week - all day offsite with Adobe. I promise to return to my normal incredibly exciting posts soon...)

Monitoring ColdFusion with FusionReactor

February 22, 2012 If your CF server starts acting up, how do you go about resolving problems? If you're on ColdFusion 8 or 9 Enterprise, you may know that you have a built-in ColdFusion Server Monitor. Did you know there is an alternative tool that supplements it well? FusionReactor is a commercial third-party tool, which can monitor not only any version of CF (6, 7, 8 or 9, whether Standard or Enterprise) but also Livecycle and any other Java web application or server in your environment. (www.fusion-reactor.com) Such monitoring is about more than "watching a screen". You can arrange to receive email alerts with valuable information (sort of a black box recording before a crash), and FusionReactor also creates really valuable logs that can also help with post-mortem analysis. They can also assist with deciding on CF server configuration settings, watch trends for hardware upgrades, and more. And as of FusionReactor 4, these logs now track information that previous only the CF Server Monitor displayed (but didn't log at all). Finally, an additional tool, FusionAnalytics, can help analyze and visualize that data over minutes, hours, days, weeks, months, and so on. In this 50-minute session, veteran CF troubleshooter and independent consultant Charlie Arehart will introduce and demonstrate these and other key features of FusionReactor (including stack tracing and crash protection), and will end with a brief demo of FusionAnaytics (www.fusion-analytics.com) Register Now: http://www.adobe.com/cfusion/event/index.cfm?event=detail&id=1965964&loc=en_us

ColdFusion offer from Intergral

Tue, 07 Feb 2012 08:38:00 -0500

Intergral, makers of FusionReactor and FusionAnalytics, have a pretty cool offer for folks buying or upgrading ColdFusion:

Intergral and Adobe Inc. are running the following promotion up to Feb 29 2012. If you purchase either a new or upgrade license to ColdFusion 9 Enterprise, you will receive FusionReactor Enterprise Server Monitor 1 Year Subscription (RRP $399), absolutely free. If you purchase a new license of ColdFusion 9 Standard, you will receive a copy of FusionReactor Standard 1 Year Subscription (RRP $249). All software must be purchased via Intergral http://www.fusion-reactor.com/adobe to be eligible for this offer. Our prices for CF are very competitive, making it all a very good deal. If you purchase Platinum Support with your new ColdFusion license, then you are entitled to receive all upgrades and updates to ColdFusion in the next 12 months following your purchase - read more http://www.adobe.com/support/programs/customer/platinum_solutions_brief.pdf

Job Opening for ColdFusion Developer at Arizona State University

Sat, 04 Feb 2012 14:42:00 -0500

Just passing it along... (btw reader - I never did want to be a 'job poster' for the CF community sinc eothers do- but I've done a couple recently. A few because they were for my last job, and one for Adobe. Do folks mind these? Find them helpful?) Web Application Developer

Job Opening for Sr. ColdFusion Developer in CA/ San Fernando Valley

Fri, 03 Feb 2012 13:41:00 -0500

Just passing it on... Job Opening for Sr. ColdFusion Developer in CA/ San Fernando Valley Position:

Senior ColdFusion Developer
Contract to hire.
Seeking an advanced-level developer who lives to push ColdFusion and Object-Oriented Web development to the edge.

Job Description

Sr. Web Developer / Architect to drive the direction of the company's technology solutions, define and implement best practices and build lean, powerful and extensible functionality.
Work closely with Business/Systems Analysts, Database Administrators, and Stakeholders to architect, design, and implement robust and user friendly insurance business applications.

More info at his blog post: Job Opening for Sr. ColdFusion Developer in CA/ San Fernando Valley

Update to my highlight/fadeout example - now with CSS hotness

Fri, 03 Feb 2012 09:28:00 -0500

Yesterday I posted an example of highlight/fadeout effects done with jQuery. It wasn't necessarily that exciting, but it's not something I've done before so it was fun to build. Fellow evangelist (and my boss, so yeah, his comments get special attention) Kevin Hoyt commented that what I had achieved would be possible with CSS and transitions.

Now - I will admit to being a bit codependent on jQuery. It's not like I'm addicted. I can stop using jQuery whenever I want to. In fact, I went out of my way to in this post. I love jQuery, but I can definitely recognize that I'm almost depending on it like a crutch, so I thought I'd take the opportunity to try it with pure CSS.

Before even approaching the idea of an animation, I thought I'd try a simple hover. That turned out to be trivial:

.tagcloudword { opacity: 0.5; } .tagcloudword:hover { opacity:1; font-weight: bold; }

That worked well enough where even if everything else I did failed, I'd be ok. Notice I also added the bold there to make it a bit more fancy. You can try this here: http://www.raymondcamden.com/demos/2012/feb/3/take2.html

I knew next to nothing about animation and transitions in CSS, but quickly found the docs at MDN to be incredibly useful. Begin with their CSS page: https://developer.mozilla.org/en/CSS. They've got a page on animations and transitions. Obviously transitions are what we want here.

I won't try to replicate the excellent docs over at MDN, but the basic gist of it seems to be this:

Define your CSS for the item.
Define your CSS for the hover.
Then tell the CSS what properties are changing, how it changes (from a list of options like ease-in), and the duration.

The only thing missing from the docs that may trip you up is the use of vendor prefixes. MDN focuses on what works for them - the moz prefix. For Chrome, I had to add webkit as well. This means you have to duplicate your code, which is kinda sucky, but passable. So here was my first update:

.tagcloudword { opacity: 0.1; -webkit-transition: opacity; -webkit-transition-timing-function: ease-out; -webkit-transition-duration: 2000ms; -moz-transition: opacity; -moz-transition-timing-function: ease-out; -moz-transition-duration: 2000ms; } .tagcloudword:hover { opacity: 1; -webkit-transition: opacity; -webkit-transition-timing-function: ease-out; -webkit-transition-duration: 2000ms; -moz-transition: opacity; -moz-transition-timing-function: ease-out; -moz-transition-duration: 2000ms; }

That's a lot of code, but if you ignore the moz lines it's really just 3 lines per state. Something else not immediately obvious to me was that if you define the transitions on hover and not on the core style block, you won't get an animation backwards from your hover state. You can demo this here: http://www.raymondcamden.com/demos/2012/feb/3/test3.html Be sure to notice that I slowed the transition down quite a bit to make it more obvious. I'd probably use 500ms instead.

Ok - finally. So how about multiple changes? Just add additional properties. Here's how I added some color too. In Chrome it seems to work really well. It goes from black to blood red to a pure red. (Don't hate me for color choices.)

.tagcloudword { opacity: 0.1; color: black; -webkit-transition: opacity,color; -webkit-transition-timing-function: ease-out; -webkit-transition-duration: 2000ms; -moz-transition: opacity,color; -moz-transition-timing-function: ease-out; -moz-transition-duration: 2000ms; } .tagcloudword:hover { opacity: 1; color: red; -webkit-transition: opacity,color; -webkit-transition-timing-function: ease-out; -webkit-transition-duration: 2000ms; -moz-transition: opacity,color; -moz-transition-timing-function: ease-out; -moz-transition-duration: 2000ms; }

You can view this one here: http://www.raymondcamden.com/demos/2012/feb/3/test4.html

It works in Chrome and Firefox. In IE9 it is not supported, but it fails ok. You still get a hover effect.

Creating a highlight/fadeout text effect on a tag cloud

Thu, 02 Feb 2012 16:17:00 -0500

Yesterday I blogged a simple example of how to turn an RSS feed into a tag cloud. Today reader JP commented that it would be cool if I could mimic an effect he saw in a Flash based tag cloud. Basically, as you mouse over each word, they light up. Here's what I came up with.

First off - I tweaked my data a bit. Instead of working with an RSS feed, I decided to hit my copy of CFBloggers and scan all the category data. My local database is a good 6 months old, but still has 48 thousand entries. This gave me a nice set of data. If you remember, Pete's tag cloud code already wraps every word with a span. The class on the span is based on the word's relative "score" compared to other words. I decided then to simply append to that:

#w#

I then added a CSS style for tagcloudword to make it a bit light by default:

.tagcloudword { opacity: 0.5; }

And then it was time for the jQuery. Turned out - it was pretty damn trivial:

$(function() { $(".tagcloudword").mouseover(function(e) { $(this).animate({opacity:1.0},400); }); $(".tagcloudword").mouseout(function(e) { $(this).animate({opacity:0.5},400); }); });

As you can see, I'm simply using the animate API to change opacity when you mouse over and out of the word. And that's it. You can even make it simpler with the hover event:

$(".tagcloudword").hover(function(e) { $(this).animate({opacity:1.0},400); },function(e) { $(this).animate({opacity:0.5},400); });

You can see a demo of this yourself by clicking the big demo button below. Note that I saved out the result as an HTML, so it's not "live".

Generate a tag cloud from an RSS feed with ColdFusion

Wed, 01 Feb 2012 15:42:00 -0500

Earlier today Mike Henke asked if there was a way to generate a tag cloud from an RSS feed. While he was able to find a solution quick enough (Wordle), I thought it would be kind of fun to try this myself. I knew that Pete Freitag had already blogged on tag clouds and ColdFusion, so all I had to do was generate my word data and pass it to his code. Here's what I came up with.

I began with a simple call to my RSS URL to generate a query of data. For my testing, this was the only thing I cached. Obviously all of my "crunching" could have been cached.

Now for the fun part. In order to use Pete's code, I need to know each word and the number of times it appears. I began with an empty struct:

Next, I created a list of "stop" words, words I'd always ignore. (Note, this list was kind of arbitrary. Also note I added some spaces in the blog entry just so it would wrap better.)

I then split by word boundary and added them to the struct. Note that this word boundary also includes ' so I can match "don't". This is not perfect, but good enough.

I had quite a few words, so I decided to remove all words with less than 5 instances.

Now comes Pete's code to generate high/low values.

And finally, the output:

`Word Cloud`

#w#

Sexy, eh? Here is the output from my blog:

I then pointed it at the RSS feed from ColdFusionBloggers:

I probably could have shortened that a lot more with my minimum filter. Anyway, I then did one more tweak. Instead of counting words, I simply took the category list:

This tag cloud then represents categories from the RSS feed:

And that's it. Totally and completely stupid, but fun. Here's the current script, although it's a bit messy. As I said, normally you would want to cache all of the crunching.

p.s. Words a bit hard to read in the pictures? Right click and open in new tab. Sorry about that!

Reminder - Adobe Cookbooks

Wed, 01 Feb 2012 10:42:00 -0500

As a gentle reminder, don't forget the excellent resource that is the Adobe Cookbook, including over 200 ColdFusion Cookbook entries. Looks like it has been a while since content was added, so take this as a gentle push to yall to consider adding something.

RIACon 2012

Mon, 30 Jan 2012 15:31:00 -0500

RIACon 2012 will be held August 6th and 7th in beautiful Rockville, MD at The Legacy Hotel and Conference Centre. The official call for speakers will begin next week, but for more information, check out the web site: http://www.riacon.com. I missed last year but hope to speak at this years conference!

Bad use of tablet space - an example

Mon, 30 Jan 2012 11:18:00 -0500

I came across something interesting in a tablet app today and I thought it was a great example of bad design. I hate to go critical, especially for a service I love, and especially since I'm no expert in tablet design myself, but I thought it would be a good illustration and a good discussion here.Late last year I discovered TripIt. Apparently everyone at Adobe uses it and I was just late to the party. It is - essentially - a way to track flights and trip information. It's real handy when you are traveling and need a quick way to look up your flights and hotel information. I used to simply copy and paste this information into an Evernote note called "Travel", and if I forgot to do so, I was screwed. Tripit makes this nicer though - especially since you can actually forward them emails from your travel agent. Anyway - go to the site - check it out - love it - etc. I've had the mobile version for some time now, but just today I decided to check out their iPad2 version. I was pretty surprised by how badly they made use of the tablet form. After selecting a trip, this is what you see: That's a heck of a lot of white space. I thought maybe I had hit the wrong button, but as far as I can see, that's the main view. To actually see your itinerary, you click the itinerary button to make it fly out: I find it really odd that the default view makes so little use of the space. Maybe there is other data that shows up there, but wouldn't the itinerary normally be the most critical information? Compare this to their Android version: I thought that was the end of it until I accidentally oriented my iPad into Landscape mode and saw this: Now that makes sense to me. So any ideas why the Portrait mode is so bare? As I said, maybe there is trip information folks store that normally show up there. I only use TripIt in a pretty basic manner so I may be missing something.

Searching across all resources in Chrome

Fri, 27 Jan 2012 16:31:00 -0500

Thanks for this goes to Paul Irish. For a while now I've been trying to find a way to search for a value across multiple files that are loaded in a browser request. But every time I used the Search field in Chrome Dev tools, it would only search the current file. I'm talking about the highlighted search field below: Yes - I know - my MSPaint skills suck. ;) As I said, that only searches the current file. If there are a bunch of JavaScript files in one request, you're screwed unless you feel like manually switching from one to another. But it turns out there's another search form you can open with ctrl-shift-f (cmd-opt-f on OSX): Not only will it search across all files (not just JavaScript), it supports case sensitivity and regex based searches as well. Anyway - thanks again to Paul for sharing the tip and I hope it helps others.

A look at JavaScript Form Validation

Fri, 27 Jan 2012 09:03:00 -0500

Validating forms with JavaScript has been possible since the very beginning of time... or at least the introduction of LiveScript (the original name before the marketing drones got ahold of it). While it's not particular new or as exciting as Canvas based games, JavaScript form validation is one of the best uses of the language (imo) and something that can dramatically improve your user's experience. I recently had a reader ask how to do JavaScript form validation so I thought it might be nice to write up a simple tutorial. This is not meant to cover every possible way, of course, and will be a very manual approach (no frameworks or plugins!) to the problem. As always, I welcome folks comments and suggestions below.

Before we write a lick of code, let's look at this topic at a high level. JavaScript form validation comes down to four basic steps:

The first thing you must do is prevent your forms from doing their default behavior - submitting. There are a few ways of doing this but our method will focus on simply listening for the submit event for the form. One tricky thing here to watch out for is ensuring our code doesn't have any errors. Yeah, sure, we should always do that, right? Well one thing that may trip you up is that if an error occurs in your code then the browser will go ahead and submit the form as if nothing happened. This is probably a good thing for the web at large, but during development it can be a bit of a pain. See my random tips at the end for a workaround for this.

The next thing is to introspect the form and figure out what needs to be checked for what. So that's part technical ("how do I know what form field X is set to?") and part business ("what fields do I care about?"). Obviously this guide can't cover every detail, but hopefully it will give you enough to go on to build more complex form validation routines.

The third concern will be reporting the error back to the user. Again, there are a couple of options here. You can use the old Alert prompt, which is ugly, but direct, or simply update the DOM with nice error messages. These can be on top of the form, to the side, underneath, or even next to the particular fields that are incorrect. Again, you've got options, but obviously you need to let the user know what in the heck is wrong.

And lastly, you must absolutely 100% no excuses test your form with JavaScript turned off. While the amount of people without JavaScript is pretty minuscule, there are far too many sites that react badly when you submit a form with JavaScript turned off. I think it's perfectly reasonable to require JavaScript and simply return nothing, or a blunt error, to a user with JavaScript turned off, but you want to ensure bad things don't happen. Assume users will not send the right form fields, will send more data then you expect, less data, etc. Your form submission page is the exhaust port of the Death Star. It's dangerous.

Ok, enough blather. Let's begin with a simple example. I've got a form with two simple fields that I will want to validate. Let's look at the code before any JavaScript code is added.

Form Validation


	username: 

	password:

If for some reason you want to run this as is, you can view it here: http://www.raymondcamden.com/demos/2012/jan/27/test1.html.

So - let's begin. I mentioned that our first task is to listen for, and take over, the form submission. We want to prevent the form from doing what it normally does - submit.

//get a handle to my form var myform = document.getElementById("myform"); //listen for submit myform.addEventListener("submit", function(e) {

In order for this to work, we had to add an ID to the form. We could get the form object other ways, but IDs are the most direct, simple way:

Now let's dig into the event handler I started earlier:

myform.addEventListener("submit", function(e) { console.log("submit"); var username = document.getElementById("username").value; var password = document.getElementById("password").value; var errors = ''; if(username == '') errors += 'Please specify a username.\n'; if(password == '') errors += 'Please specify a password.\n'; if(errors != '') { alert(errors); e.preventDefault(); } });

For our form, we want to check the values of the username and password field and ensure they have something in them. My first two lines grab the fields and their values using getElementById. Those of you used to jQuery know that the framework makes this call a bit simpler, but as I said in the beginning I'm intentionally ignoring frameworks for now. I also create a simple errors string variable. This will store the text I'll show to the user in case an error.

The next block begins my simple validation. In my case, I'm just comparing both values to empty strings. Not the most complex validation, but it works. (For extra credit, I could have trimmed the space from my inputs. I've been to many forms that let me bypass their validation by just hitting the space bar.) Note how for each "rule" I simply append to the errors string. This then let's me check if the string is blank. If it isn't, it means something went wrong. I use the alert feature to tell the user.

Here's a critical part. I want to ensure the form does not proceed as normal. Without this one line, it would: e.preventDefault(). e is the name of the variable that the browser will pass the Event object in. Think of it as the actual form submission event. It's not the form, it's the action of me clicking submit.

If you want to test this, use the URL here. Note that I did NOT bother building a file to accept the form input. something.php doesn't exist. If that confuses people, I'll put in a handler, but for now, expect a 404 when the form submits: http://www.raymondcamden.com/demos/2012/jan/27/test2.html

And here is the complete page:

Form Validation username: password:

So, that works, but is a bit ugly. Let's get rid of the alert. It smells of 1997. How about inserting some text into the page instead? I added a new div, and relevant style, to my page:

...

The div is empty for now which means the user won't see it until I actually put something in it. Now instead of creating an alert, I'm going to just inject HTML into the div. I modified my error messages to use BR tags. (In case it wasn't clear, the alert uses line breaks, \n, to create the breaks.)

if(username == '') errors += 'Please specify a username. '; if(password == '') errors += 'Please specify a password. ';

And to inject it, I modify the div's innerHTML property:

var errorDiv = document.getElementById("errorDiv"); if(errors != '') { errorDiv.innerHTML=errors; e.preventDefault(); } else errorDiv.innerHTML='';

So - what's up with the else there? When the user hits the form, it's possible that they will make some type of mistake. When they do, a message is added into the div. When they correct the mistake and hit submit, the form submission will go along as normal. But if the form processor is slow, then the user will continue to see the error message. By clearing it, we remove any doubt in the user's mind that their form is being processed.

You can demo this here: http://www.raymondcamden.com/demos/2012/jan/27/test3.html The full code is below:

Form Validation


	

	username: 

	password:

Alrighty... now that we've got the basics down, it's time to kick it up a notch. Let's begin by looking at a slightly more complex form:


    
	name: 
	
	
	
	bio: 
    
    
    
    gender: 

    
    
    
    favorite colors:

     Red

     Blue

     Green

    

    
    favorite food:

     Pizza

     Beer

     Cookies

We've now got a text field, a textarea, a select box, a set of checkboxes, and a radio group. The code we used earlier to grab form values will need to be updated a bit. So for example, we can't just get the value of a set of checkboxes.

In order to simplify things a bit, we're going to upgrade our code a bit to something more modern - the Selectors API. Roughly, this gives us jQuery-style APIs to the DOm and simplifies things for us quite a bit, especially in terms of our radio/checkbox groups. The API comes down to two main method: querySelector and querySelectorAll. I recommend this blog entry for a good introduction: HTML5 selectors API -- It's like a Swiss Army Knife for the DOM. This is - yet again - one more cool aspect of HTML5 that seems to be passed over for demos of Canvas apps and kittens. Sigh. That being said, the support for this is actually rather good. When we talk about support and HTML features, typically the bugaboo is IE. In this case, IE8 and above supports the feature. Good enough for me. Let's look at one change:

var myform = document.getElementById("myform");

versus:

var myform = document.querySelector("#myform");

Not too terribly different, right? And if you are used to jQuery then this is familiar. You aren't saving a lot of keystrokes here, but wait, it gets better. Let's take a look at how we grab some of these form fields:

var name = document.querySelector("#name").value; var bio = document.querySelector("#bio").value;

Ok - not too different. Basically we just get to the DOM via the newer API versus the older one. How about the select? Well, select fields have a selectedIndex. Our business rule will be to simply ensure the first item isn't picked, so all we care about is the index.

var gender = document.querySelector("#gender").selectedIndex;

Ok, now it's time to get fancy. How do we ensure our users pick at least one from the checkbox group? We could use document.getElementById for all four fields and ensure at least one has their checked property set to true. That's not horrible per se, but it's a lot of typing I would hope we can skip. Our radio group has same validation rule. How can we do this nice and easy?

var colorcbs = document.querySelectorAll("input[name='favcolor']:checked"); var foodcbs = document.querySelectorAll("input[name='favfood']:checked");

Let's look at the first one since the second example is the same ignoring the name. Our selector is: input[name='favcolor']:checked. Reading left to right we have: Give me input fields that have an attribute name with the value favcolor, and filter to those that are checked. Or in English - what did I check in the favcolor group? These two calls both return an array of DOM items for any checked field. What's cool is that I can then just check the length of this array. This would also let me support things like, "Pick at least one favorite food but no more than three." Let's take a look now at the validation code:

if(name == '') errors += 'Enter a name. '; //bio not required if(gender == 0) errors += 'Select a gender. ' if(colorcbs.length == 0) errors += 'Select a favorite color. '; if(foodcbs.length == 0) errors += 'Select a favorite food. ';

Not too difficult, right? You can view the full demo here: http://www.raymondcamden.com/demos/2012/jan/27/test4.html

And here is the complete template:

Form Validation


	

    
	name: 
	
	
	
	bio: 
    
    
    
    gender: 

    
    
    
    favorite colors:

     Red

     Blue

     Green

    

    
    favorite food:

     Pizza

     Beer

     Cookies

So... what do you think? If you've never worked with JavaScript, or are just beginning, does this make sense? Any question?

p.s. So I mentioned above that one of the things you have to watch our for is errors in your submit handler. One way to work around that - at least in Chrome - is to enable Console/Preserve log upon navigation. This will keep the error in your log even after the form goes to the submit page.

A database utility class for PhoneGap

Thu, 26 Jan 2012 08:36:00 -0500

I've done a few projects now that make use of PhoneGap's database support. Like most things in PhoneGap, it just plain works. But I've encountered a few things I thought could be done a bit easier, so I've built a simple utility class for my future projects. I thought I'd share it with folks and see if it would be useful for others.

My utility library has the following features:

executeBatch: Given a file path (via URL), you can have PhoneGap read in an XML file that contains a set of SQL commands. So for example:

myDbController.executeBatch("sql/createtables.xml",successHandler,errHandler);

Where your XML would look like so:

create table foo if not exists foo(....) create table moo if not exists foo(....)

This was done to support the fact that unlike Adobe AIR, the SQLite support in PhoneGap doesn't allow you to ship a pre-populated database. (Although it is possible via a workaround: Prepopulate SQLite DataBase in PhoneGap Application.) The syntax for this was based on work from my fellow evangelist, Christope Coenraets.

executeSql: As you can guess, this simply wraps up executing SQL. While PhoneGap doesn't make this necessarily hard, I found the API a bit awkward in terms of all the callbacks you had to use. ("All" sounds like a lot - it's more like two - but you get the idea.) So for example:

dbController.executeSql("select * from notes", gotNote, errHandler);

The other nice thing this will do is automatically take the result set and return it as a simple array of objects. Again, it's not difficult to work with the normal result set, this is just a bit simpler.

Finally, the class has a simple init() handler that sets up your connections for you. What makes it nice is that it can also automatically call your batch scripts for you. So for example:

dbController.init("main","data/seed.xml",dbReady);

The code is below and is free to use by anyone.



New Adobe Inspire Magazine out (with an article by yours truly...)
Wed, 25 Jan 2012 08:22:00 -0500
The title says it all. The latest issue of Adobe's Inspire Magazine is out. There's lots of good content with the only low point being my own article (grin) on PhoneGap: Combining your web skills with PhoneGap to build mobile apps. Probably nothing new for folks who read my blog entries here.






PhoneGap RSS Reader - Part 3
Tue, 24 Jan 2012 17:10:00 -0500
Welcome to my third entry for my (what was at first) simple PhoneGap RSS reader. If you haven't yet, please be sure to read part 1 and part 2 so you have some context about how this application works. In this part, I'm going to tackle two enhancements suggested to me by my readers:


First - support rendering the entries if the user is offline.
Second - clean up the UX a bit so that when a user views an entry, leaves, and then comes back to another entry, they don't see the old text there for a split second.




Let's tackle the offline question first. I spent some time thinking about this and tried a few things that didn't quite work out the way I wanted. The first thing I tried was checking navigator.onLine. (See this Stackoverflow entry for details.) This did not work well for me. When I switched my device to airplane mode it still reported me as online. I then looked into PhoneGap's Connection API. This kinda worked. It didn't seem to grok my Airplane mode at all. It certainly didn't report it as online (it returned a null actually) and I could have handled it, but I then had the issue of how I was going to handle coordinating the deviceready event along with the jQuery Mobile pageinit method.



Then I realized something. I already had an Ajax error handler. And it worked. That's obvious of course, but it occurred to me. Why not use this error handler? It would not only support offline mode, but any error on the remote server as well. At the end of the day, if I can't get the RSS feed, who cares if I'm offline or if the server is down. I could see caring, and if so, you would obviously want to use the PhoneGap Connection value, but I figured, why not go with the simple route.



As for storage - that turned out to be trivial - LocalStorage. Have you guys figured out yet that I really love HTML5 LocalStorage? 



So, I decided to get rid of AjaxSetup. I only have one Ajax call in the entire application, so why not tie it to that call. So I switched from a $.get to a $.ajax:




$.ajax({
	url:RSS,
	success:function(res,code) {
		entries = [];
		var xml = $(res);
		var items = xml.find("item");
		$.each(items, function(i, v) {
			entry = { 
				title:$(v).find("title").text(), 
				link:$(v).find("link").text(), 
				description:$.trim($(v).find("description").text())
			};
			entries.push(entry);
		});
		//store entries
		localStorage["entries"] = JSON.stringify(entries);
		renderEntries(entries);
	},
	error:function(jqXHR,status,error) {
		//try to use cache
		if(localStorage["entries"]) {
			$("#status").html("Using cached version...");
			entries = JSON.parse(localStorage["entries"])
			renderEntries(entries);				
		} else {
			$("#status").html("Sorry, we are unable to get the RSS and there is no cache.");
		}
	}
})




This is - for the most part, the same code as before, just using the core $.ajax method. You can see where the error function will look into LocalStorage for the cached copy, and where the success function always stores a copy. The renderEntries function is simply an abstracted out version of the display code:




function renderEntries(entries) {
    var s = '';
    $.each(entries, function(i, v) {
        s += '
' + v.title + '
';
    });
    $("#linksList").html(s);
    $("#linksList").listview("refresh");		
}




Woot. That works. Now for the next request. We want to ensure that users don't see the old content when loading in the RSS entry detail page. This turned out to be a bit weird. jQuery Mobile has logic to say, "Do this when a page is hiding, or before it hides", but for the life of me (and please correct me if I'm wrong) there doesn't seem to be a good way to get the page that is leaving. You get passed the page you are going to, but not the current page. I really feel like I'm missing something here, so please note this may get corrected later. For me though I simply added an event listener to the main page. It now sees if a previous page exists, and if so, clears out the text:




$("#mainPage").live("pagebeforeshow", function(event,data) {
	if(data.prevPage.length) {
		$("h1", data.prevPage).text("");
		$("#entryText", data.prevPage).html("");
	};
});




And that's it. I've included the entire JavaScript file below (the HTML hasn't changed from the previous entry) and a zip of the entire project may be downloaded for the low cost of free.







//EDIT THESE LINES
//Title of the blog
var TITLE = "ColdFusion Jedi";
//RSS url
var RSS = "http://feedproxy.google.com/RaymondCamdensColdfusionBlog";
//Stores entries
var entries = [];
var selectedEntry = "";

//listen for detail links
$(".contentLink").live("click", function() {
	selectedEntry = $(this).data("entryid");
});

function renderEntries(entries) {
    var s = '';
    $.each(entries, function(i, v) {
        s += '
' + v.title + '
';
    });
    $("#linksList").html(s);
    $("#linksList").listview("refresh");		
}

//Listen for main page
$("#mainPage").live("pageinit", function() {
	//Set the title
	$("h1", this).text(TITLE);
	
	$.ajax({
		url:RSS,
		success:function(res,code) {
			entries = [];
			var xml = $(res);
			var items = xml.find("item");
			$.each(items, function(i, v) {
				entry = { 
					title:$(v).find("title").text(), 
					link:$(v).find("link").text(), 
					description:$.trim($(v).find("description").text())
				};
				entries.push(entry);
			});
			//store entries
			localStorage["entries"] = JSON.stringify(entries);
			renderEntries(entries);
		},
		error:function(jqXHR,status,error) {
			//try to use cache
			if(localStorage["entries"]) {
				$("#status").html("Using cached version...");
				entries = JSON.parse(localStorage["entries"])
				renderEntries(entries);				
			} else {
				$("#status").html("Sorry, we are unable to get the RSS and there is no cache.");
			}
		}
	});
	
});

$("#mainPage").live("pagebeforeshow", function(event,data) {
	if(data.prevPage.length) {
		$("h1", data.prevPage).text("");
		$("#entryText", data.prevPage).html("");
	};
});

//Listen for the content page to load
$("#contentPage").live("pageshow", function(prepage) {
	//Set the title
	$("h1", this).text(entries[selectedEntry].title);
	var contentHTML = "";
	contentHTML += entries[selectedEntry].description;
	contentHTML += 'Read Entry on Site';
	$("#entryText",this).html(contentHTML);
});