Well, while this is not for the faint of heart, I found a cool trick that I bet a lot of people might like to see… And no no… it’s not so much “elite” as it is “asinine”, but since when did ANY hack not connote that? I’m pretty sure the #1 way to win a job interview for a coding job is to walk in with a shirt that says:
“For all your bug attraction needs, use “Mr. Clever Hack” the all purpose coding spray”
*ahem* Disclaimer aside, let’s go on
So, I have effect clusters that are similar to the cluster examples in the SPRY Cluster Sample page ( link ). But, I want it to work with images, and each image is differently sized, and to make it even crazier, the image is contained in a paged view, which means it will only be available at runtime… there’s no predifined, static declaration system that would work short of making a whole new xml document and maintaining it with my images (ICK! who wants to do that?). Here’s how I did it, with a bit of CSS and Spry debugging help (the spry debugger will help you get a grasp on the harder things to manage).
Here’s the key concepts:
You can always have access to the height of the image if you keep it somewhere hidden (which the cluster allows). So I just nest another Div inside the div for the image… I called one “#Comic_Display” and the other “#Comic_Image”. Just make sure that these are UNIQUE (hence the ID’s), or you will have trouble figuring out which image to get a height from (ie, if you had fifteen divs called “Comic_Image”, you’d have to go through a lot more work to access the pertinent image dimensions).
HACK #1: Using spry to access an element from the client side
This handy line will allow me to, at any time, see the height of the Comic_Image div.
Spry.$$("#Comic_Image")[0].clientWidth
Spry.$$("#Comic_Image")[0].clientHeight
Of course, the $$ function grabs the DOM element via the css id it has (so make sure it’s unique!).
Notice that [0] which is going to be pertinent only if you have more than one “#Comic_Image”. This is also cool because if you did have multiple images, you now have a way to iterate through them via the array index so that you can average the dimensions (that way you could maybe find a way to normalize the images).
After you choose an index, client width and height are the functions that grab the display size of the image. You’ll want to test this on your platforms. If this hack doesn’t work, you might have to find a different way to get the width…
HACK #2: Making the clusters change their properties (this has a lot of setup, so bear with me)
If you have the spry debugger on a page somewhere, try making a “new Spry.Effect.
Every size effect ends up having these member variables:
startWidth
startHeight
stopWidth
stopHeight
To change our effect inside the cluster, we just need to refer to it, and command it like so:
EffectReference.startwidth = somewidth;
Let me show you my exact way I pulled it off… then you can chortle quietly at my horrific coding mannerisms and peeves (oh the joy).
I define my cluster constructor like so: (look at the spry sample page for hints as to what this does… you really almost need to know nothing about what this is doing… just pay attention to a trick here:
var comicSqueeze;
//this will hold a reference to our effect so we can change it
var my_cluster = function(element, wid, hei)
{
Spry.Effect.Cluster.call(this, {toggle: true});
this.name = 'my_cluster';
///
//Assume there are already several clustered
//effects in here, for simplicity, I'll only show one
///
var resize_ver = new Spry.Effect.Size(element, {width:wid, height: 10, units:'px'},
{width:wid, height: 1000, units:'px'},
{duration: 500, toggle: true, finish:
function () {
contentTransition=false;
} } );
//this finish function allows me to reset the
this.addNextEffect(resize_ver); //transition state. You'll want to put this in
//your last effect in a cluster that might be
//clicked several times on accident...
comicSqueeze = resize_ver; //using this little diddy, we can have a handle on our comic squeezing
}
Now then, that’s fine and dandy, eh? This function creates a cluster (I assume you know how to attach it to your own cluster class, right? Just comment on this article if you want help), but it isn’t dynamic. Yet, it does use the global “comicSqueeze” to give us a reference to the resize function.
Now, everytime we need to transition, I use this classy function: (assume I’ve already declared and initialized my cluster with the call “clusterList = new my_cluster(”Comic_Display”,a,b);” where a and b can be arbitrary heights or widths.)
function transition(){
if (contentTransition){//this keeps the user from knocking our cluster out of whack
return;
}
else {
contentTransition = true;//ensure that we are the only ones starting a transition
comicSqueeze.stopHeight = Spry.$$("#Comic_Img")[0].clientHeight;
clusterList.start();
return;
}
}
See the cheap trick? So, I just use my handle “comicSqueeze” to change the height by looking up the client height. Simple trick, but the possibilities are pretty high and mighty.
I’ll stop talking about my handles so you people can stop holding your ears in offense. Have fun, and comment if you have questions (I must admit, it’s a very unorthodox trick to get the clusters to update)