In my last post about page controllers, Jason Holden asked on which pages I use page controllers. This is a great question and speaks to a larger issue of code organization that applies to CSS and JavaScript as well.

[More]

While working on a form that makes use of some simple AJAX, I discovered that using a Page Controller can make this easier - especially when combined with JSMX.

[More]

I try to avoid blog posts that just repeat what has been said elsewhere, but this is really nice.

I blogged earlier (mid-2005) about a JavaScript version of cfdump. I actually used this recently to help me implement JSMX (which I love!).

I saw an entry today the strikefish blog about another JavaScript CFDUMP which looks great. The advantage of this one is that the output more closely matches the output and behavior of cfdump. I like this in part because the format is familiar and in part because it is a really useful format.

If you just want to see the tool, take a look at JavaScript Dump. 

I just found an interesting article by Pete Forde arguing against the "next" button and paging through records entirely.

He even points to an example or two of how this could be done. 

His point is basically that since the web is non-linear, pages don't make sense. After all, the contents of "page 2" today won't necessarily match the contents of "page 2" tomorrow.

[More]

Today I was working on some AJAX code and realized that I would rather get my data from a CFC than from XML data. A few minutes of research later and I have JSMX up and running.

I already had a CFC with the method I needed to get my data with access="remote" (hopefully more on why I have this later - a new approach that seems promising). I thought it would be nice to add another remote method to generate the XML I needed for my AJAX.

This turned out to be rather easy, but I had to set returntype="void" and output="yes" and output the XML straight to the CFC page. This worked, but seemed a bit "hacky".

I was sure that someone had thought of a better way, so off to Google I went to find it.

JSMX advertises itself as an AJAX API - which it is (actually it advertises itself as "The Universal AJAX API"). It has some distinct advantages over other AJAX APIs that I have looked at (and never used). For one, it is just one 13K JS file. For another, it can easily digest data in a number of formats.

Notably, it can digest WDDX data. This is significant because that is the format of data you get if you do an HTTP "Get" on a remote method in a CFC.

The site has a few good examples of use , but none on WDDX. I was unable to find out how it structured the WDDX data in JavaScript. Fortunately, DP_Debug came to the rescue. This is basically cfdump for JavaScript - very handy.

I used the following syntax to test the results:

<script type="text/javascript">
http('GET', 'mycomp.cfc?method=mymethod', DP_Debug.dump);
DP_Debug.dump(MyObject)
</script>

This revealed that the results are basically identical to what you would get if you used <cfwddx> with action="CFML2JS". This made the JavaScript to digest the data even easier than it was to digest the XML.

My steps to implement JSMX:

1. Copy the .js file to my site.
2. Reference the .js file on my page.
3. Change my JavaScript syntax appropriately (about a 5 minute job in my case) 

The result is that my JavaScript got smaller and easier to use and I was able to remove the file to serve up XML data and rely on the CFC to provide that data.

My only complaint about JSMX so far is that it could be much smaller than 13K if the comments and white-space were removed. Other than that small complaint, it is a thing of beauty!

cfdump is such a handy utility in ColdFusion. I have always wanted a similar utility for JavaScript. Now there is one!

I thought of trying to write such a utility myself, but the task seemed, well, daunting. Fortuntately, Depressed Press of Boston has tackled the project that I never would have done myself. I haven't used it yet, but I very much look forward to it.

For those of you that aren't familiar with cfdump, it outputs the contents of a simple or complex ColdFusion variable, similarly, dpDump() output the contents of a simple of complex JavaScript variable. I imagine that this will come in very handy during debugging.

Read about dpDump().

Thanks Depressed Press of Boston!

Over time I have found a handful of nifty little JavaScript utilities. I was about to compile a handy reference of them for myself when I realized that others might be interested in them as well.

These are scripts that I have used and liked as well as some scripts that I haven't used book look nifty.

Here they are in no order:

General

• Bill Rawlinson's Unobtrusive Sortable Tables
  
• Expandable list using DOM
• Tabtastic
• qForms
• jComponents
• DynArch DHTML/JavaScript Calendar
• Tigra Color Picker
• Tigra Calendar
  
• Tigra Tree Menu
• ActiveWidgets
• XML for JavaScript
• Matt Kruse's JavaScript Toolbox
  

Menus

• Son of Suckerfish
  
• Project Seven
• Milonic
• DynArch Menu
• UDM 4
  

WYSIWYG Editors

• HTMLArea
• FCKeditor
• TinyMCE
  
• XStandard
• widgEditor

Let me know of any other scripts that I should add to the list.

On the CF-Talk list, Richard Colman asked how he could keep a session alive for longer than the 30 minute limit imposed by Crystal Tech.

Michael Dawson provided a very good answer (quoted below):

I setup my intranet so that, even if the session times-out, it will be transparent to the end-user. I do this by keeping a separate session cookie.

When the session times-out, then the user accesses another page in the application, my scripts will reload the data in the session scope again. The end-users have not complained about this process.

In addition to that approach, I would suggest the following bit of JavaScript:

function keepAlive() {
    var imgAlive = new Image();
    var d = new Date();
    imgAlive.src = '/alive.cfm?d=' + d;
}
setInterval("keepAlive()", 20*60*1000);

Before the script is added to your site, add a small alive.cfm file to the root of your site (name it whatever you wish, just be consistent). The script makes sure that a page is requested from your ColdFusion server by their browser every 20 minutes (safely less than the 30 minute time-out). Alive.cfm need not return an image - JavaScript doesn't check.

Keep in mind that this only works for users who have JavaScript enabled, so make sure to use this technique in conjuction with (not in place of) the approach suggested by Michael Dawson.

This technique actually has a great many uses that I will try to post in future entries. I have used it in the past to change database data without a form submit and also for JavaScript error handling.

Update!

Martin Perry added this suggestion to the discussion to get around the JavaScript issue:

Alternatively, to get around the JavaScript bit, create an invisible IFRAME which has it SRC set to the alive.cfm.. On Alive.cfm, add a HTTP redirect to redirect back to itself after 1200 seconds.

<META HTTP-EQUIV="Refresh" CONTENT="1200;URL=/alive.cfm?cachebuster=<cfoutput>#createUUID()#</cfoutput>">

I never think about IFRAME myself (trying to remain standards compliant). Nevertheless, it is an excellent suggestion. Good call Martin!