The worst part about writing a book (which just arrived today – no, this is NOT an April Fools joke), is the fact that print is so damned permanent. And once the chapter leaves your word processor and heads off into editorial production land, there is no easy way to “fix” a mistake or update a topic. And just this very thing happened with the project in Chapter 6 of the book.

In that chapter, Stephanie and I wrote about using the Spry Framework for Ajax to create an art gallery. In approaching the project, we chose to use the “new” Sliding Panels widget which was added in the 1.6 release of Spry. Unfortunately, what I didn’t “notice” during the writing of the chapter was that the panel sort of stuttered when clicking upon the panel navigation the first time after the page load. Apparently this is something that others have seen as well, because I was recently asked about that very problem in an online seminar that Stephanie was presenting and in which I was frantically answering questions in the chat window. So, there’s the issue and, more importantly, here’s the fix.

First of all, let me say, the documentation that accompanies the Spry Framework is very good. And, as is typical, every one of the examples works wonderfully and are very inspirational. In fact, if you copy and paste the code and modify it to suit your needs, you may never run into any problems. Unfortunately, none of the documentation addresses the issue that we were seeing. And of course, all of the samples work perfectly.

So, what’s the problem with our version? Well, although I pride myself on my own investigative prowess, it took one of the Spry engineers to point out the issue. It all revolves around the approach that we used in finishing off the page. Let me clairfy.

In the example in Chapter 6, we first built the page with all of the Ajax functionality added directly (read: obtrusively) to the page. And in fact, that’s why I didn’t notice the stutter until it was too late. With the code sitting in the page itself (in my case, at the end of the document) everything worked fine. But because we wanted the page to validate properly, we did not want any <script> tags within the document itself. I then created an external JavaScript to unobtrusively add the Spry functionality to the page. And that’s where things went awry.

In order for the Sliding Panels widget to work, it must understand how much data (in other words, how many individual panels) that it needs to page through, and in turn be prepared to navigate with the first click. This is normally done with all Spry widgets by placing their “construction script” at the bottom of the HTML page preceding the </body> tag, or alternatively at the end of the element itself (such as a div). This is the way it is in the included example files in the Spry 1.6 download, and the way that Dreamweaver inserts the widgets included in the Insert panel. By placing the script at the end of the document (or element), it is the last thing to be executed. In other words, the page is built, data processed and placed in the page, and then the interface elements (Spry widgets) are initialized.

However, in the external JavaScript (externalJavaScript.js in the completed source files for the chapter, and step 13 on page 326 of the book), you can see that I initially moved the code that creates the Sliding Panel out of the original HTML page to make it unobtrusive and appended it to the external script – adding it to the Spry.Utils.addLoadListener function which is used to add the Spry markup to the HTML elements.

Spry.Utils.addLoadListener(function() {
...
var sp = new Spry.Widget.SlidingPanels("slidingGallery");
...
});

And therein lies the problem – the Sliding Panel is being created along with everything else during the loading of the page, as I mentioned before. To correct the problem, we need to move the line above out of the LoadListener, because we need to delay its construction. To do this, we must use an observer attached to the element that will become the Sliding Panel, instructing the browser/framework to hold off with the construction of the Sliding Panel until after it has completed processing the data and adding it to the page markup.

I’ve done this by adding the following code above the Spry.Utils.addLoadListener code:

Spry.Data.Region.addObserver("slidingGallery", { onPostUpdate:
function()
{
sp = new Spry.Widget.SlidingPanels("slidingGallery");
}});

The Spry.Data.Region.addObserver instructs the framework to pay attention to the data being loaded into the identified element, in this case “slidingGallery”. Then listen for it finish and report back when everything is processed and in place. Upon receiving the word that everything is ready (the Update event), the onPostUpdate event then fires with its function instructing the Spry Framework to go ahead and attach the Sliding Panels’ behaviors to the slidingGallery element, turning it into a Sliding Panel ready to be navigated through – and there’s no more st-st-stutter.

I hope this clears things up – otherwise, leave a comment or question and I’ll be happy to answer it. And btw, you can see the finished site that we used as the basis for the book chapter at Rive Gauche Galleries. Click in and visit an artist’s page to see the Sliding Panel in action. And, if your browser has the capability, turn JavaScript off and reload the page to see how wonderful the Spry Framework can degrade using the new HTML Dataset capabilities. Cheers!