[Looking for Charlie's main web site?]

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

Note: This blog post is from 2008. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
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.

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

Note: This blog post is from 2006. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
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.

Copyright ©2024 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