[Looking for Charlie's main web site?]

Grokking JQuery: A useful editorial overview by Rick Strahl (and why you may like him beyond that)

Folks interested in another take on jQuery may appreciate learning of this overview, jQuery Puts the Fun Back into Browser Scripting. The author does a great job of helping folks "grok" the tool at a high level. Now, it ends with some discussion of using it with .NET, but it's not enough to diminish the value for CFers. Indeed, just as the author notes that it can be used with or instead of ASP.NET ajax features, so the same is true with CF8 (and certainly for those using earlier releases of CF.) And of course, jQuery is about far more than just ajax.

If you've wondered what the hubub was about, give it a look. And if you want to read more about jQuery from the CF community's perspective, check out the blogs of folks like Ben Nadel, Rey Bango, and John Farrar, to name just a couple.

As for the article above, I'll add that the author is Rick Strahl, who, while not a CFer, has still been one of my favorite writers/bloggers over the years. Why? Well, first, he's just very thorough and a good communicator. But he also came from a Foxpro background and so his writing has often been (especially early on) from the same sort of "outside the camp" perspective that we CFers sometimes have. Admittedly, he's recently focused more on .NET and I know some CFers will just choke on that, but if you can look past it you may find nuggets of gold in his writing as I have. Besides the blog, he has a list of articles you can dig through, as well as some free tools which might be of value.

Using Atlas (MS Ajax Toolkit) with CF, and getting CF / Atlas example working

Have you wondered about using Microsoft's Atlas tookit with CF? You can. It helps, though, to recognize that the toolkit is composed of multiple parts, one of which is a purely client-side toolkit and which can certainly work with CF. There's even sample code to demonstrate it.

Before I point that out, let me clarify that Atlas has also been renamed recently and is now named in ways that recognize the different parts. The client portion is now called the Microsoft Ajax Library.

There's a demo zip showing CF/Atlas integration available at the blog of the MS Developer who presented it at CFunited, Brad Adams. As discussed in the blog and comments, just unzip the file into your web server root. Assuming you leave it named AtlasCF, you need not change the code--except for one thing.

If you have CF Debugging turned on, the app will fail to work (without any message). Of course, the debugging will cause his CFM page (called from the Atlas client) to send the big load of HTML debugging info at the bottom of its output--and his Atlas client obviously won't be expecting that.

The simple solution is to drop:

<CFSETTING ShowDebugOutput="no">

into the application.cfm.

Sadly, he's got comments turned off so I can't offer this there, though I have emailed him and hope he may update the blog entry.

Perhaps others out there are also doing CF/Atlas integration. If so, drop some comments here for others who may be interested to hear.

Flex 2 / CF Presentation by Ben Forta, now online

If you're looking for yet another avenue of introduction to Flex and its intergration with CF, particularly a free one-hour Breeze session, check out the recording of BEn's presentation from a couple weeks ago:


On that page, select ColdFusion or Flex from the product list on the right, and on the resulting page, don't be thrown off by the title, "Government: Building Rich Internet Applications". It's of value to all viewers.

As Ben is wont to do, he avoids being powerpoint-centric and jumps right into some generic Flex demos first, and then 20 minutes into it starts to really talk about Flex/CF integration. There's about 5 minutes of discussion after that and then he jumps into code-centric demos, showing the CF-related integration in some flex code and in the Flex Builder, including the wizard. By about 45 minutes he instead starts coding Flex/CF integration manually within the builder, which some may find compelling. There is Q&A throughout (which as always in Breezo's is a bit of a struggle, torn between answering questions and staying on topic) and a lot of Q & A at the end, which many may especially enjoy.

I-Spry Part 4: Help. Spry/Ajax isn't working: problems due to unexpected server results

As you begin exploring Spry, or indeed any Ajax solution, there's going to be a point when you'll be stumped with something just not working, and no amount of eyeballing the CFML or HTML source will help...because the problem is between the browser and the server--in the http stream. In this entry, I want to share some common problems and solutions. In the next entry, I'll discuss tools to help solve that problem. This is vital stuff.

(As suggested in the entry's title, this is part of a series I'm doing on Spry. Be sure to check out the other entries.)

Problems Due to CFML Debugging Being Turned On

While most Spry examples show simply opening XML files, most CFML folks will be inclined to try to generate the XML via CFML. Nothing wrong with that. In fact, I'll have a future entry on some tips there.

But if you do decide to try to generate the XML from CFML, you need to be very careful: Spry apps (and indeed many Ajax apps) expect XML--and only XML--to be received in response to their httprequest. A very common problem/mistake is to leave your CFML debugging turned on. You may even look at your page and say "it IS returning XML", but it's not. It's the XML PLUS the debugging output. And what's that written in? HTML!


The simple solution is either to turn off debugging in the requested CFML page or its application.cfm/cfc, using:

<CFSETTING ShowDebugOutput="no">
or turning it off server-wide in the CF/BD server Admin console.

Problems Due to text/HTML mimetype Being Returned

Another common stumper, depending on how you try to return your XML from CFML, is that while you're trying to send XML, the CFML engine is doing something that you never perhaps noticed. What have we always genereated (for the most part) from CFML pages? Why, HTML, of course.

Well, under the covers, web servers (and app servers like CF/BD) happen to also set what's called the "mime type" for the generated page, and by default they create it to be "text/html". The problem is that a client (like Spry/Ajax) that's expecting XML may balk at that header/mime type.


The solution may be to set the correct mime type in the requested template or its application.cfm/cfc. You can do that with:

<cfcontent type="text/xml">
. You may even find that it's useful to add the RESET="yes" attribute to that tag, which aborts any previous output generated prior to the tag. I'll share as well that sometimes CFSILENT and CFPROCESSINGDIRECTIVE can be helpful to manage whitespace.

I said above that the problem may depend "on how you try to return your XML from CFML", and that the CFCONTENT "may be" the solution. The thing is that you may also find you can return your XML from CFML in ways that automatically handle that detail, such as using CFFunction's ReturnType="xml", which has changed as of 7.02. More on that later (or in the meantime see other entries in my Spry compendium).

Problems Due to Errors in CFML Page Sending XML

Continuing from the above, think also of what happens if you're requesting a CFML page (that's supposed to be returning XML) and instead there's an error in the page. What does CF (and BD) return? By default, it's the traditional runtime error page. Well, think about it: what's that written in? It's HTML, again! We never think about it in normal CFML coding, because we just see the error in the browser and read the words and go a-debuggin'.

But the code reading the result of the XMLHttpRequest in Spry (and in many Ajax solutions) is not as smart as us. If it's expecting XML, and your error causes it to get HTML, it will be totally stumped.


The reasonable solution would seem to be to setup your server/application to use CFML error handling (CFERROR, CFTRY/CFCATCH) so that you catch the error and send back a message in XML. But that's not as obvious as it may seem. First, your Spry client is going to be witten so that the Spry.Data.XMLDataSet expects not just ANY XML but XML in a specific nested structure of specific element names. It will not be trivial to package up an error in a format useful to the client.

This is an area where the Spry framework itself could help us. Since the focus for now is on developers of simple static HTML, and indeed on reading simple static XML, it's something that I don't expect would be a high priority for the Spry team. I haven't investigated this with them, though, and will welcome any correction of miunderstanding/misstatement.

The problem of generating "spry-client-specific XML" is still more challenging if you try to setup this error handling in your application.cfm/cfc using CFERROR, but you have pages that are both general-purpose CFML templates browsed by browsers, and those meant to serve up XML. You may want to separate the XML files into their own directory, so as to handle them (and the debugging issue above), separately from the traditional CFML pages. Otherwise, you would need to detect whether the client is not a regular browser, but think about it, how will you know if the client is "not a regular browser"?

All these issues above are not really a new problem. We faced the same challenges some years ago in the "old" days of generating WAP/WML pages from CFML (WML was a way of creating web pages for phones, using an XML-compliant language to layout content for phones). I wrote of many of these same issues in a chapter I did in the book, Professional WAP in 2000.

I should add, as well, that the subject of CFML error handling (CFERROR, CFTRY/CFCATCH, and more) is a topic worthy of multiple blog entries. Instead, I'll point you to a series of CFDJ articles I did on the topic:

Problems due to web server error messages

Similar to the issues of CFML error messages above, think also of the implication of general web server messages. Even if your Spry request asks for a static file (really, any file) from the server which, due to some error (like not existing) would would lead the web server to respond with an error. It's likely that, again, the web server will respond with an error message also formatted in HTML.


There are different solutions for web server error message handling, but it's beyond the scope of this discussion. I'll just raise the issue for you to consider. I can even foresee web servers perhaps getting smart about detecting the browser type and trying to return a particular type of error, but as was discussed above, this may always be problematic.

A Better Debugging Tool

With all the problems above, and still more, which can cause the server to respond with something that your Spry/Ajax client didn't expect, the better idea is for you to be armed with a tool to help you observe the communicaitons stream between your browser and the server. That's a very important point, which I will save for a later post.

I-Spry Part 2:Considering Spry as a CFML developer

In this 2nd part of a series I'm starting on Spry, I've heard or seen various discussions about Spry from some CFML developers, who see the code and/or demos creating dynamic tables and ask, "couldn't I just have done that in CFML?" Well, sure, you could, but think outside the box.

(As suggested in the entry's title, this is part of a series I'm doing on Spry. Be sure to check out the other entries.)

Spry is a client-side tool, first and foremost

Spry is a client-side tool, so on one level it's supposed to appeal to non-CFML developers, who don't have CFML (or PHP, ASP.NET or J2EE) to generate their HTML dynamically.

Spry is about processing XML received

More important, though, even for we CFML developers, you need to think beyond "just creating dynamic tables": the real goal of Spry is to process XML being sent to the client.

Consider, for instance, the situation where you don't control the XML being generated. Perhaps it's coming from an RSS feed or some other xml-generating product on your server (or on some other server, that perhaps you proxy on the spry request's behalf--more on that later, or in the Spry docs).

The point is that you may not then be able to (or want to bother) creating the display in CFML, leaving it instead to Spry to handle.

Spry is about more than "generating dynamic tables"

And Spry can certainly do much more than just create tables. It can create virtually any HTML code based on the data received. Tables are just a simple example most can grasp. We're already starting to see many other and more interesting examples.

Spry is about detecting and responding to page content and source data changes

Still more important, the real value in Spry--and it's true Ajax raison d'ĂȘtre (reason for being) is to do automatic regeneration of content based on changes to the source XML data or other selections on the page, which can include asynchronous communication on the client's behalf back to the server.

That's where things like the dynamic regeneration of regions (which change when the dataset their bound to changes) and master/detail "data references" (where data in one region changes based on selections in another region)really makes things different than "static" HTML you could build "dynamically" in CFML (or other web app platforms).

As I say in my Spry compendium discussed in my previous post, do take the time to learn more from the many available resources, especially the 2 key 30+page documents from Adobe. You'll get a whole new appreciation for what Spry can do for you.

Even so, do look for more posts here as I share some of the other common tips and traps I've hit as I (and others) have explored Spry.

Beyond those comments on looking at Spry as a CFML developer (comparing and contrasting how we might do things one way or the other), there are also a few other comments on why you should be interested in Spry.

Spry is about reducing bandwidth

Those who were around when Flash came out will recall that a big part of its advantages was that it permitted redesign of pages so that rather than transmit the entire page on each "request", the Flash client just requested the data needed to fill a given area of a page.

The same is true with Spry (and Ajax in general). If you can change an interface to retrieve just the needed data (rather than the full weight of an entire HTML page), that can make a big difference in performance and cost savings (hey, someone has to pay for that bandwidth in sending HTML from a server).

Spry is about reducing Javascript complexity

Going back to the first point, all this power comes in a package of tags that dramatically reduce the complexity of the coding needed to enable all these (and more) features. It's possible to create powerful interfaces and interactions with no (or just a tiny amount of) Javascript.

Sure, as we create more advanced interfaces, we may need to understand and use more Javascript. The good news is that both built-in and community-generated demos will help show the way in the near term, and in the long term I'll bet that more work from Adobe in the Spry framework itself will help make still more powerful interfaces just as easy and low in Javascript coding.

Spry is about reducing Browser Interoperability hassles

If you've looked at doing Ajax, you may or may not have had a hassle dealing with whether your code will work on one browser or another. Sure, most Ajax frameworks also try to hide that complexity, but just know that Spry does as well, which is a good thing if you have to deal with supporting different browsers.

There is even an approach to graceful degregation, or what Adobe calls "Progressive Enhancement", discussed at the end of Adobe's great 35-page article, Spry Data Set and Dynamic Region Overview, leveraging something called Hijax methodology.

Admittedly, if the browser doesn't support Javascript at all, that's a separate challenge and a bummer. The challenge of detecting and handling when JS is disabled is not really new to Ajax at all, and I'll leave that to the reader to research or for others (or a later entry here) to elaborate on.

I-Spry Part 1: A compendium of Spry resources for CFML developers

As the first of a multi-part series I'd like to do on Spry (Adobe's Ajax framework), I've just put together a Spry Resource Compendium. As more and more CFML developers become enamored of Spry, or hear others extolling it, they may benefit from knowing about several available resources to help you get started. Some you may find more readily than others.

(As suggested in the entry's title, this is part of a series I'm doing on Spry. Be sure to check out the other entries.)

I've gathered together several of them, both to save you the work of trying to find them and more important to help you avoid missing key ones, especially ones that focus on CFML-related aspects.

Check it out, at:


I'll try to keep it up to date with new community resources as they're offered, but of course some of the Adobe-provided compendium resources (pointed to on my page) will ultimately become the best place to find resources in the future. For now, I'm just trying to help while there are scattered resources. Drop me a note if you see something I should add.

An interesting short video on Ajax, from Manning (Ajax in Action)

Saw this offer of free short video intros to Ajax (4 minutes and 20 minutes) and thought it may interest some:

Free Screencast: What is Ajax
Get a taste of what Ajax is all about. Watch the entertaining and informative four minute overview [QT7 8MB] [MP4 12MB] or choose the more detailed demonstration with examples in our twenty-two minute screencast

It's from the folks at Manning Publications, publishers of Ajax in Action.

Copyright ©2018 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting