the singularity of being and nothingness
Posts tagged Spry
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 > Coming Soon…Very Soon!
Jun 10th
Remember the CSS Gallery I wrote about a while ago? Yes, the one that I'm building? Well, IT'S ALMOST DONE!!
I am incredibly excited. The design, I feel, really came together, and the final result is something simple and sleek, but still (at least IMO) memorable.
One of the most exciting things about this project for me is that it's allowed me to flex some ColdFusion 8 muscles–muscles that I have had not yet really had a chance to use until now.
What kind of features are there going to be? I'm glad you asked!
On the client side, I completely Web 2.0-ified the site submission process. When you click "Submit", instead of getting redirected to a form page, I'm using Thickbox to present the form. The form itself is pretty sweet, too. First, there's a fairly interesting hint tool that I developed. But the power of the form is that not only does it check the XHTML and CSS validation on the site you enter while you're finishing up the form, but even the form submission itself is AJAXed. No stupid submit and refresh here!
Once a site submission is approved and live, each site will have comments attached, as well as a rating mechanism. As 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 >
