Note: This blog post is from 2006. Some content, links and indeed comments from others may be outdated--though not necessarily. Corrections are welcome, in the comments. I may revise the content if 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 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.