Jaco’s Random Writings

So my little project I’ve been working on was a slideshow in Flash, specifically Actionscript 3. I decided that I wanted to see if I could program something in Flash without actually using Flash or even Flex Builder. I decided to use the Flex SDK (free) with the Eclipse IDE (also free). Combined with the AXDT Eclipse plugin (free) and LuminicBox (also free), and I got myself a pretty powerful AS3/Flex/Air development platform* at the cost of $0. Eventually most other people fork over the cash and get either Flash or Flex Builder, I might also, but for the time being, I’ll stick to this.

There are quite literally hundreds of Flash slideshows out there. To write one from scratch these days is pretty counter-productive. However, most of them require that you use an XML form to enter the locations of the pictures. A separate XML form for myself and my clients to maintain? This will not do. So, I figured, “Hey! xHTML is XML too! Why not feed the xHTML that the SWF is embedded in back into the SWF and parse that like regular XML?” Theoretically, it sounds pretty simple and makes perfect sense. That’s one of the reasons why many people code in xHTML versus plain-jane HTML. So after about 2 weeks of coding and grinding and experimenting, I got a working slideshow together. Now, I decided to write every component of the slideshow from scratch. Well, to say it was written completely from scratch is a bit of a stretch. I copied a lot of example code and improved on it (most of the code coming from the actual AS3/Flex documentation examples).

While I would love to embed the slideshow here to show everyone, I can’t. There are a few limitations to this approach that I’ll explain in a bit. Instead, click here to see the slideshow in action. Do take a look at the page source to see how the images and parameters are presented.

So essentially, here’s how it works:

1. Loads in external parameters and saves them to global variables. This includes things like whether debug is running or not (believe it or not, you don’t want debugging to be running constantly. Slows things down a lot). Other parameters include required things like the xHTML filename, the id of the <object> containing the embedded SWF, and optional parameters** like the style of transitions and the delay between slide changes.
2. Using the xHTML filename, it loads the xHTML document, validates it as XML, applies the xHTML namespace***, and parses the xHTML document for the images. Specifically, it looks for the <object> tag it was embedded in (this is where the id for the tag comes in handy), and pulls the src attribute of the <img> tags nested in it.
3. Using the data is snagged from the src attributes, it then loads the images in, adding each image into a stack.
4. Once all images are loaded (and it checks for that), the interval timer is started. This timer sets the delay between the slide transitions to be 5 seconds. This can be changed with an optional parameter to however many seconds the image needs to be up.
5. When time comes for a transition, the slideshow checks to see what type of transition it should use. By default, it uses “none”, meaning that it simply moves the image at the top of the stack to the bottom. No frills. No animation. No pizazz. However, this can be changed via an optional parameter to 1 of 9 transition styles: slide up, slide down, slide left, slide right, fade out, fade left, fade right, fade up, and fade down. I might add more over time if people ask for it.

There are a couple of shortcomings that I’m running into with my implementation of this principle. It has to load the xHTML from the server via the .html file. This, of course, won’t work at all if the file that the page is generated from PHP, ASP, or any other server-side scripting language. For this to work with dynamically generated pages, I would have to either one of two things:

1. Contact the server via Flash or some other source that Flash can activate, and have the server run the PHP and send back the generated xHTML. If that’s even possible, then I don’t know how to do that. Will probably have to turn this into a Flex app… which I think would over-complicate this entirely.
2. Use JavaScript or some other way for the SWF to get the generated xHTML document from the browser. This may require the use of some dubious Javascript.

So the short of it is that this slideshow doesn’t work with blogs or dynamically generated pages. At least, not in its current form. I intend on doing some serious research on this and making a branch of this to handle that (and eventually merging that back into the code-base).

Basically, right now, this slideshow is good for people who don’t want to muck about with XML and want to implement a slideshow in a static xHTML page. This isn’t really necessary for blogs, since most blogs have plugins that allow for the insertion of Flash slideshows without mucking about in XML. As for dynamically generated pages… I’ll have to work on that.

Footnotes:

* If you would like to put together a setup like this one, Jake Hilton provides a fantastic tutorial on how to get it working. An important note on getting LuminicBox working: The main SWF for LuminicBox, FlashInspector.swf, needs to be running off of a web server or a local server (via a LAMP stack or similar). This has to do with how Flex SDK compiles the SWF. However, if you run FlashInspector through a local server, the slideshow page needs to be access via that server as well. I found that out the hard way so that you you don’t have to.
** Right now, the parameters are passed via a FlashVars query string. I really wish there was a better method than this, but I can’t find one that doesn’t require some pretty dubious JavaScript.
*** If you’re going to work with xHTML as XML in Flash, you really want to read this article. Turns out that all the xHTML in a document is under a namespace for xHTML. It’s declared when you type <html xmlns="http://www.w3.org/1999/xhtml"> in the document. Flash absolutely, positively will not parse xHTML if the namespace isn’t declared. Read the linked article and you’ll spare yourself hours and possibly days of painful debugging.