Does the introduction of Spry UI mean that Spry development is alive and well, and that Adobe is committed to making something of it long term?  Only time will tell. 

The problem for me, of course, is that time is precisely the problem.  Development of the framework has been seemingly eternal, and significant updates (whether features or simply information about ongoing development) are VERY infrequent.  While I see a lot of promise in what Spry can do (and can become), "facts on the ground" force me to use other, more mature frameworks for serious development.  

I don't mean this as a slight to Spry, nor to the talented Spry team (or even the thousands of developers who make really good use of it).  The bottom line for me is that I need a framework today that has the fully formed features of a jQuery or Ext.  If Spry Framework is in that position tomorrow, I'll more than happily give it a another chance.

The reason for this, of course, is simple: out of the gates, thickbox.js fires off an initialization function (tb_init) through jQuery's ready().  What this means, technically, is that thickbox has already started its processing and element fishing before Spry's data sets have been fully loaded and rendered.  What this means, practically, is that Thickbox won't work.

Though frustrating, there is a fairly simple way to work around this.  

Conceptually, what we'll be doing is to bypass jQuery's ready() function and load tb_init manually AFTER we know Spry's data sets have fully loaded and rendered.

First, we need to figure out when the data sets are done processing.  This is pretty simple, because Spry comes with a handy way of sniffing this out.

We'll start by setting up a new data region observer.  Our observer will watch the data set and when it reaches the "state" that we define, we can manually fire the thickbox.js processing.

So here's our new observer:

the_Observer= new Object()
the_Observer.onPostUpdate = function() {
   // Here's where the thickbox function call will go…    
};

Spry.Data.Region.addObserver("the_region", the_Observer);

Nothing too complicated here.  We create a new Spry region observer, tell it to watch for the "onPostUpdate" state, and then we can load in whatever processing we want to the function we've defined for that state.

The next step, then, is to load in the thickbox initialization function.

To do this, start by going to the thickbox.js file.  Copy the following lines:

tb_init('a.thickbox, area.thickbox, input.thickbox');
imgLoader = new Image();// preload image
imgLoader.src = tb_pathToImage;

Once you have them copied, go ahead and comment out the entire $(document).ready function, including the lines you just copied.  Save and close.

Go back to your other page and paste the three lines into our observer function.  The final result will look something like this:

the_Observer= new Object()
the_Observer.onPostUpdate = function() {
    // See?  Here's the init function for thickbox…
    tb_init('a.thickbox, area.thickbox, input.thickbox');
     imgLoader = new Image();// preload image
     imgLoader.src = tb_pathToImage;
};

Spry.Data.Region.addObserver("products", the_Observer);

That's all there is to it.  Now your Thickbox content should work correctly.

For example:

Spry.Utils.addEventListener("myButton","click",doMyFunction,false);

This one line of code adds an eventListener to the element "myButton" for the onclick event, which will fire "doMyFunction()".  And it's just as easy to remove the same eventListener:

Spry.Utils.removeEventListener("myButton","click",doMyFunction,false);

Easy enough.  However, I recently found myself wanting to not only add and remove eventListeners, but also to check if they exist for certain elements.  Luckily, before digging into the DOM to much, I checked SpryDOMUtils.js–sure enough, there's a function already built for this.

In fact, as you may or may not be aware, you can run Spry.Utils.addEventListener() on an element as many times as you like–only one eventListener will be registered.  This is because addEventListener() runs a check to see if the eventListener is already registered, and proceeds from there (look at line 166 in SpryDOMUtils.js v. 0.6 to see this in action).

So checking to see if an eventListener is registered for an element is exactly the same as adding and removing the eventListener.  Here's what it looks like:

Spry.Utils.eventListenerIsBoundToElement("myButton,"click",doMyFunction,false);

This will return true or false, and you can do whatever you'd like from there. 

without the need for any postbacks to the server.  I've done this thing several times before, but in the past, I've done it very inefficiently.  Let me give you an example.

Let's say I'm building a list of songs to put on my mp3 player.  I start with a list of all the songs from my media library, as well as a blank list that's waiting to be filled up with songs for the play list. In the past, what I've done is create two Spry data connections to a database, one to manage the play list, and one to manage the full list of songs.

Of course, this is easy enough to do, but I wanted to make it a bit better.  For example, when selecting a song, I wanted to be able to show that the song was selected (and also make it un-selectable again).  

My past approach would have been to start with an onclick event to handle the data saving.  Once this process was complete, I would have fired a complete reload of both my datasets–when they would reload, the song I added would appear in the play list and the song I selected would now be flagged with a "IN_PLAYLIST" tag that would instruct whatever event listeners I had set up to ignore this until it was removed from the play list.

So this works, but it's horribly inefficient.  First, and most glaring, is that two full rounds to the server are made for every 1 song that is added to the playlist (or removed).  Second, and related, is that this does not take advanatage of easy DOM manipulation of these elements that could have saved some server round trips.  Third, it's just not very elegant, and makes the whole experience feel a bit disjointed.

Not satisified with this, I decided to really dig into doing this better when a similar bit of application work came around.I started by eliminating one of the server requests.  Since I'm going to do this without reloading the dataset from the database, I can load the "playlist" dataset without Spry and do it all on server.  Easy enough.  

So now I'm down to one dataset for my "current library".  In the code, I'm passing some information from my query about each song in the "current library," and each song that is in the playlist is marked with a boolean in a column labeled "IN_PLAYLIST".  In my HTML, I'm using a spry:if to evaluate this column, which determines what kind of image shows up next to the song (e.g., whether or not it is selectable).

From here, I'm using some standard JS to transfer all the details of the selected song to the playlist dataset.  Additionally, I'm using JS to manipulate the "selected" element so that it is no longer selected AND gives an indication that it is somehow different from the rest of the "current library" in that it is "in" the playlist dataset. Again, easy enough.

It's at right about this time that I run smack into a huge problem.  You see, all this time I've been using a Spry dataset for the "current library" songs, but I've also been paging these using SpryPagedView.js.  For some reason, even after modifying the newly selected elements through JS, if I navigate between the pages of the paged view dataset, all of the changes I make (well, at least those that are related to the spry:if) are reverted to their original form (e.g., what they looked like when I initially loaded the page).  So what's happening?  
Well, first of all, I apologize if I don't get this 100% right in my explanation, but you'll see how my understanding eventually led to a solution.

When a paged view dataset is created, all of the initial data elements are stored in various arrays.  When you navigate between pages, Spry evaluates each 'page' based on a few variables (page size, page number, etc) and uses the result to go back to these arrays and populate the data shown based on these.  Note especially that this happens every time a page in the paged view is selected.

This means that if you have a spry:if in your code, Spry runs over that for EVERY PAGE of the paged view, and does it EVERY TIME you navigate between pages.

Of course, this answers the question of what was happening to my code above.  Even though I was modifying the HTML elements of the "current library" to display based on selections, Spry didn't care what I had done once I changed the "page" of the paged view.  Rather, Spry re-evaluated the spry:if's, and re-rendered the element based on that.  Whatever parts of my changes that were in conflict with the spry:if were overwritten.

So obviously, simply modifying the HTML element itself is not enough to achieve the desired functionality. 

But never fear, for the solution is actually pretty simple. All we have to do in addition to modifying the HTML element is to also modify the array from which Spry is pulling its data each time.  As I mentioned, this is surprising simple to do.

For paged datasets, Spry stores the data items in an object called "unfilteredData".  So if my paged recordset is "pvRecords", the path in the DOM to the unfiltered data is simply "pvRecords.unfilteredData".  Now that I've accessed the array, I can search through the data items in it to find the one I want and modify it to the updated value.  Now, when

Spry evaluates the spry:if in the code, it uses the new value updated in the unfilteredData array, and renders correctly.

Here's an example of what I've done:

function modifySpryDataReference(title,dir) {

    var uds    = pvRecordsAlt.unfilteredData;
    for(i=0;i<uds.length;i++) {
        if(uds[i].TITLE == title) {
            uds[i].IN_PLAYLIST=dir;
        }
    }
}

In this example, I simply loop over the contents of the unfiltered dataset, looking for the item whose title matches the argument I pass to the function.  If a match is found, I access the "IN_PLAYLIST" item and change the boolean to whichever "direction" I'm going (e.g., whether I'm adding or removing a song from the playlist).  

So yeah, it's not too bad of a thing to do, and it helps to give a little better perspective/understanding on what Spry is doing under the covers

Recently, we ran into an issue at work.  We're constantly adding JavaScript functionality to our company intranet.  While adding references to JavaScript files in the master pages that drive the templates is easy to do, there is a process that all master page changes have to go through, and this can limit the desirability of future changes.  What we needed was a way to dynamically load JavaScript files when needed, so that only the core init.js file that is loaded with every page request needs to be referenced on the master pages.

I've never done this kind of thing before, so I did a little snooping around.  There are apparently alot of solutions out there, some of them better and more robust than others.  After studying what they do, I decided to try my hand at building a simple JS loader in Spry, given that the core files I need are already in place.  Here's the result:

Spry.Utils.addLoadListener(function() { addEventHandlers() });

var wiki = 'wikicontent';

function addEventHandlers() {    if (Spry.$$(wiki)) {        loadJS('js/showlinks.js')        getLinks();    }}

function loadJS(file) {    var syncJS = Spry.Utils.loadURL("GET",file,false,addJS);    }

function addJS(req){    if (window.location.href.indexOf("http")==-1 || req.xhRequest.status==200) {        var head = document.getElementsByTagName('head')[0];         newJS = document.createElement('script');        newJS.setAttribute('type', 'text/javascript');        newJS.text = req.xhRequest.responseText;        head.appendChild(newJS);        }} 

Turns out this is really easy.  The first thing you'll want to do, of course, is check to see if the element/function/etc that needs special JavaScript loaded exists.  In my example, I'm checking to see if the div that wraps a wiki element exists.

If it does, I call the loadJS() function (yes, I know, quite original!).  This function is really a go-between function that allows the meat of the process–the URL load–to be independant of this context and, therefore, reusable.  It takes only one argument: the relative path to the JavaScript file that needs to be loaded.

This argument is then passed to an instance of the Spry.loadURL function.  This function will make a synchronous XMLHttpRequest to the specified URL.  Easy.

Now for the most important part.  When the XMLHttpRequest returns a value, it needs to be written back to the DOM so that the functions included in the JavaScript file will be available for use.  This is accomplished on the callback function of the loadURL(), 'addJS'.  This function bascially takes the returned XML response, parses it, and writes it to a new script tag, which we create.  Finally, the new script tag is appended to the "head" tag of the page.

BIG GOTCHA:  IE7 will not recognize "innerHTML" for the script tag, so you have to use "text".  

That's it.  Now all functions and variable available in the requested JavaScript file are immediately available for use–in fact, this example makes a call to "getLinks()", the core function of the "showlinks.js" file.

Now obviously, this is an extremely simple example, and more complicated scenarios will require more processing, more capturing of errors, etc.  And one downside is that for this example, it require that SpryData.js, SpryDOMUtils.js, and an init.js be loaded with the page.  This could get a bit expensive, and less elegant (IMO) methods of accomplishing the same thing can occur with a tad less overhead.  Nonetheless, if you can spare the fractionally greater load times, it provides a simple way to make your coding even more flexible…and it uses Spry, to boot!

One thing I've been frustrated with is Spry's effects. While they have some good effects, I never found them particularly flexible or usable beyond little dynamic enhacements. Apparently, most of this is because I hadn't read the documentation enough.

Enter effect clustering. Normally, Spry effects run in turn of function call: so if you have, say, a tool-tip that you want to fade out and move, these effects would run in order (which wouldn't really make sense to do anyway). However, as I discovered with great joy yesterday, Spry allows for something called "effect clustering" which allows any number of effects to be run in parallel with one another.

I about peed my pants when I found this out, it's so cool and useful. So here's an example of this in action.

And here's the code:

FadeMove = function(element, options) {    Spry.Effect.Cluster.call(this, options);

    var duration = 1000;    var toggle = 'false';    var from = 100;    var to = 0;    var fromPos = new Spry.Effect.Utils.Position();        fromPos.x = 13;        fromPos.y = 0;    var toPos = new Spry.Effect.Utils.Position();        toPos.x = 13;        toPos.y = -65;    Spry.Effect.makePositioned(element);

    var transition = Spry.fifthTransition;

    if (options) {        if (options.duration != null) duration = options.duration;        if (options.from != null) from = options.from;        if (options.to != null) to = options.to;        if (options.transition != null) transition = options.transition;    }

    var fadeOut = new Spry.Effect.Fade(element, {duration: 500, from: from, to: to, transition: transition, toggle: toggle});    var moveUp = new Spry.Effect.Move(element, fromPos, toPos,{duration: 800, transition: transition, toggle: toggle});

    this.addParallelEffect(fadeOut);    this.addParallelEffect(moveUp);};

FadeMove.prototype = new Spry.Effect.Cluster();FadeMove.prototype.constructor = FadeMove;

Honestly, this is super-easy to do. You start by extending the Cluster class–any effects that you include in this extension now become a cluster.

FadeMove = function(element, options) {    Spry.Effect.Cluster.call(this, options);    .............}FadeMove.prototype = new Spry.Effect.Cluster();FadeMove.prototype.constructor = FadeMove;

In this example, I want to have an effect that "fades" and "moves", so I called my class extension "FadeMove." You can call it whatever you want.

The next thing to do is to setup some default options for the effects you're going to be using:

var duration = 1000;    var toggle = 'false';    var from = 100;    var to = 0;    if (options) {        if (options.duration != null) duration = options.duration;        if (options.from != null) from = options.from;        if (options.to != null) to = options.to;        if (options.transition != null) transition = options.transition;    }

The function allows you to pass in your own options dynamically, so these are just here as a safety net.

Next, define your effects, just as you normally would for any Spry effect call:

var fadeOut = new Spry.Effect.Fade(element, {duration: 500, from: from, to: to, transition: transition, toggle: toggle});    var moveUp = new Spry.Effect.Move(element, fromPos, toPos,{duration: 800, transition: transition, toggle: toggle});

Simple. So now the only thing left to do is to tell the function that you'd like to have these effects run in parallel. As with all things Spry, this is cake:

this.addParallelEffect(fadeOut);this.addParallelEffect(moveUp);

Guess what? That's it. There is nothing more to it than that. Seriously, I am completely psyched about abusing this new knowledge on all my projects. Be sure to check out my example.

Yet fortuitously, a couple days ago I was browsing the Spry docs and noticed two very promising words: Rating Widget.

Surely this cannot be what I'm looking for, could it? Ah but it was!

Recently, Spry updated its growing library of widgets to include a standard "star" rating system. Like it's other widgets, the rating widget comes with a single css file and a single javascript file. And also like other Spry widgets, it is completely simple to implement.

Assuming you have referenced the css and javascript files correctly, here's all it takes to set up a star rating system:

<span id="myrating" class="ratingContainer">

        <span class="ratingButton"></span>        <span class="ratingButton"></span>        <span class="ratingButton"></span>        <span class="ratingButton"></span>        <span class="ratingButton"></span>        <input type="text" id="ratingValue" name="dynamic_rate"/>        <span class="ratingRatedMsg">Thanks for voting !</span>    </span> 

It's so simple it's almost laughable. But it gets much better. Like all things Spry, this widget makes it incredibly easy to connect with other files that might handle server-side processing (such as computing the new average of votes based on user's selection). To do this, you just add an additional parameter to the widget that specifies the file that will be doing the processing, as well as any arguments that need to be sent along. Spry takes care of the rest. Oh, and there is also a handy parameter ('afterRating") that allows you to easily update the widget with the returned value from the original request, all completely asynchronously. And here's that:

var rate = new Spry.Widget.Rating("myrating", {ratingValue:2, afterRating:'serverValue', saveUrl: "rating.cfc?method=returnAverage",postData:"id=myrating&rating=@@ratingValue@@"});

Here, I simply instantiate a new widget, set a default rating "average" (2), specify the 'afterRating' to get the returned serverValue, and setup my url fetch with appropriate arguments. Absolute cake!

Check out an extremely stripped down version of all that the Spry rating widget is capable of doing.

Oh, and tomorrow I will follow up on this regarding how we move this already cool widget to full-on unobtrusiveness.

However, probably the biggest time-saver is making a concerted effort to make my JavaScript unobtrusive. What is this, you say? Well, by no means does it have a solidified meaning. However, a few principles are core to any definition.

The first is the idea of abstracting the functionality of JavaScript (be it data handling or effect processing) from the design layer on which the functionality is placed. In short, this means that the HTML markup of a site (and its corresponding CSS) should not be dependent on the functionality of JavaScript; rather, the functionality of JavaScript should be "pluggable" into the markup that it finds.

Now of course, this is all-too-idealistic. There is never a scenario in which markup and functionality are mutually ambivalent towards one another. However, the premise is still sound. Even as style (CSS) and markup (HTML) should live cohesively, yet independantly, so should JavaScript and HTML.

This means, then, the end of inline JavaScript function calls. No more "<img src='foo.jpg' onclick='doFoo()' />'. The answer? Register an event-listener that will perform the exact same functionality, but will additionally not be render-glued to the HTML to which the action is applied.

Now believe me, I've only been doing this for just a few months and I've quickly found that registering event-listeners and all the other fun unobtrusive novelties of JavaScript IS A LOT OF WORK! It's simple to slap down some inline function calls, but requires more thought when registering event listeners. Plus, you have to think about the implications of 'bubbling', the possibility of a need to remove these event-listeners, etc.

At first glance, it does not seem worth it. More complex code, more work. Hmm, maybe I'll pass. But wait! There are HUGE benefits.

The first (and most important in my mind) is that inevitably, unobtrusive JavaScript SAVES time. Even though it takes more time initially to setup, the long-term benefits to an application are innumerable.

Consider a scenario where you have a very simple, routine function that has inline processing on, say, 15 pages. What happens if you need/want to change the name of that function, or any arguments that might be passed in it? Well, you're screwed. You'll have to run through 15 pages, making sure to make the correct modifications to the appropriate peices.

With unobtrusive JavaScript, however, this problem disappears completely. As long as the markup remains the same across those pages, a change to a function that affects those 15 HTML elements is as simple as a single change to a single file that manages the event-listeners for those elements. Just stopping there, the argument for unobtrusive JavaScript is won.

However, it gets better.

Some JavaScript libraries use *funky*, non-standards-compliant special tags for their inline processing. While the JavaScript works brilliantly, W3C will pitch a fit about the non-compliant code that has been generated. So why are these tags created in the first place? Well, they are simple ways for the JavaScript framework to find its special elements and apply the necessary processing to them. But with unobtrusive JavaScript, these non-compliant tags are rendered completely unnecessary. Because elements and events are being defined in abstraction from the markup, there is no need to identify inline areas for processing. These elements have already been identified independantly of the markup, and can therefore be processed for the JavaScript framework as if nothing has changed.

Without question, my brief description of the benefits of unobtrusive JavaScript hardly does justice to the promise that it holds for seriously robust development, and I have not even mentioned the way in which it aids the development of accessible content. Nonetheless, I am very excited about what can be done with it, and hope that this is an inspriing discussion to other designers who are looking for better and more efficient ways to create richer experiences on the web.

One of the limitations I pointed out was the initial amount of coding involved. Well, that was because I'm an idiot.

While I've used Spry's Spry.Data.XMLDataSet() many times before, I literally had no idea how powerful it is, nor that it could interact with dynamically generated XML files, such as I was doing with ColdFusion components in my last example. However, such is not the case. Not only does this method allow me to do everything I was doing before, it involves a heck of lot less code. The entire invoke for the datasets here is:

var dsCities = new Spry.Data.XMLDataSet("getlocations.cfc method=getCities", "cities/city");

var dsLocations = new Spry.Data.XMLDataSet("getlocations.cfc?method=getLocations&cityID={dsCities::@id}", "locations/location");

Two lines of javascript! Now of course, there is more to handle some of the behaviors…but I have effectively cut out about 100 lines from what I was doing before. Pretty cool!

Finally, the best part about this is it allows me to take full advantage of the framework's "spry:state". With this, one can set different "states" that will fire in relation to the loading of the datasets. So, while the data is loading, one can display a sexy progress gif using "spry:state=loading". And when the dataset is retrieved, one can use "spry:state=ready" to display the returned datasets.

Oh yeah, one LAST thing. Using datasets like this makes dynamic callbacks a breeze. Imagine I have items that a user can save to their "favorites". Using the "spry:if", I can tell the browser to display certain elements certain ways depending on the recordsets that are returned (i.e., whether or not the user has a particular item saved to their favorites). Before Spry, I would have the user "save" the favorite which would reload the page, re-hit the database, and alter the display to show the changes to the data. With Spry, however, the page reload is no longer necessary. Rather, one can simply tell the callback function from the insert query to recompile the Spry dataset asychronously. Because the data that's currently being display is based on this dataset, the returned information will be refreshed automatically, all without the need of a single page reload.

Blah, blah, blah. Enough of this. Here's a slightly more sexy example of what I've been talking about.

While ColdFusion 8 has some seriously cool AJAX features built into it that handle alot of this kind of thing with ease, it is not free and wonderful hosting companies (like GoDaddy) are slow to upgrade their servers to the newest version. Therefore, the onus is upon the developer to utilize the various work-arounds until ColdFusion 8 is firmly entrenched.

One tool that makes life significantly easier is Adobe's Spry Framework . While Spry includes a lot of the cool effects of other Javascript frameworks, one of the best parts of it is the easy way in which it allows Spry to make server-side calls to allow applications to harness normally off-limits server-side functionality asychronously. For example, consider that I wish to display a list of businesses by city. I want to be able to display the businesses by city, as well as all without a filter on the city. To accomplish this without Javascript and ColdFusion alone, the standard practice would be to give each city link an ID that would be passed to the URL string. Then, when the page reloads, the variable passed to the URL string would tell the database to only show the records that are relevant to that variable.

While this works, it is not very sexy. It requires page reload after page reload just to see different information. Blah. Enter Spry. With Spry, the functionality works exactly the same. A variable is passed through a URL that tells the database to only return certain records. However, what is different is that Spry does not need page reloads. Rather, being the sexy little thing that it is, Spry is able to pass the variable to ColdFusion, get ColdFusion to process the variable on the server, return the variable to Spry, and then output it for the user to see—all without a single page reload.

While this is a great solution for the end user, it does require a bit more effort on the development side. With ColdFusion, I could normally do the database call, data processing, and data ouput in about 20 lines of code. Using Spry, however, has significantly increased that number, for besides having to outline–in Javascript–the various xhtml elements that I wish to populate with data, I also have convert my database queries to an XML format that Spry will be content to use.

Nonetheless, I think the number of lines of code is justifiable, and as I do this more, the coding time will be signficantly reduced. Plus, I think the end result is pretty dang cool.

Interested? You can see a very unsexy example here .