the singularity of being and nothingness
Spry Framework
New Spry Enhancements
May 1st
Even though I've pretty much given up on Adobe's Spry Framework, I noticed yesterday that some major updates have been added in, primary among them the introduction of Spry UI. According to the Spry Team's blog post, Spry UI is a new way of approaching Spry widgets that moves away from the previous (and kind of annoying) necessity of following a prescribed markup model and now attempts to work with user-defined patterns. This *should* allow for much more flexibility and customizability, and allow for much more robust opportunities for skinning that were previously possible. Moreover, because all the widgets will now inherit from the same shared base classes, the door is widened for Spry to become a much more robust framework in the future.
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 More >
Using Spry Data with Thickbox
May 15th
If you've ever tried to use Spry data sets with a default implementation of Thickbox (a jQuery-based version of the familiar Lightbox), you've probably noticed that it doesn't work.
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 More >
Checking if Spry eventListener Exists
May 3rd
So if you use Spry, you know that adding an eventListener to anything is super-simple. It's easy to add, and managing the processing that occurs on events is pretty intuitive.
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 More >
Manipulating Spry Datasets in the DOM
May 1st
I recently created a little peice of functionality using Spry data to setup two lists that can swap data on the fly,
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 More >
Dynamically Loading JavaScript…with Spry!
Dec 23rd
I've written a couple of articles in the last few months about my adventures in JavaScript. While I certainly don't claim to be even proficient, I am getting better day by day. As I pick up tricks and tips, I try to pass them on to help others out (hopefully!).
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 More >
Flippin' Cool Spry Goodness
Sep 1st
As followers of this blog know, I am a pretty big fan of Adobe's JavaScript framework, Spry. Admittedly, it's not a super-huge framework like jQuery, but I like its simplicity and how rapidly I can develop a solution with it.
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 = More > Spry's Rating Widget
Apr 16th
For a new project I'm working on, I will need a mechanism for users to vote on certain pieces of content. Now it turns out that there are a billion and one ways of doing this, with an additional billion sets of frameworks. I was quite overwhelmed by the number of choices, so I've been putting it off for a while now.
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 More >
Unobtrusive JavaScript…Duh!
Apr 15th
As I develop more applications that leverage JavaScript–both for data manipulation AND for superfluous effects–the more I come to realize the inexpressible need for finding as many shortcuts as possible. Without exception, as my JavaScript becomes more involved, so the complexity increases exponentially. To remedy this, I've started relying on frameworks such as Adobe's Spry, mooTools, jQuery, etc. to make my life easier for everything from element selection to major effects processing.
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 More >
Adobe's Spry Framework, Part Second
Mar 24th
A couple days ago, I posted an example of how Adobe's Spry Framework allows one to easily and quickly incorporate XML datasets into an application, allowing for a great alternative to page-to-page navigation and data mining.
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 More >
Web 2.0 Goodness – Adobe's Spry Framework
Mar 24th
Ok, so as everyone who reads this blog knows (or should know…), I am a web designer/web developer. On the development side, I am best at ColdFusion , one of the under-appreciated programming langugages out there. While ColdFusion is awesome, one of the drawbacks of it (as well as of PHP, .NET, etc.) is that it is a server-side technology, meaning (surprise, surprise) that all of the code processing done is accomplished on the server. So, any of the cool Web 2.0 stuff out there, like asynchronous form submission, has to use Javascript.
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 More >
