On slideshows :
Before the templating engine, before the database abstraction class and before the weblog API there was the slideshow tool. We've all written them. They all suck. Partly because there is too much to keep track of and every widget tries to accomodate every step : the images; the scaled images; the list and ordering the of images (how many times have you sullied your file names with0045_ prefixes?); the meta data or commentary associated with an image; the look and feel of the actual webpages. And while an all-in-one package is always fun my experience has been that, in a slideshow, context, they usually come at the price of zero-flexibility. Apache::Album is a pretty good example. It is a very cool and very easy widget to set up. But, the HTML is hard-coded and meta data is stored free-form in YA file that sits in the image directory and it only outputs HTML. So, I spent the better part of two months, a while back, tearing the guts of the package apart trying to make it more flexible with things like subclasses for output formats, XPath-itis for meta data and all manner of bells and whistles. I learned a bunch of stuff in the process but ultimately failed to create anything more flexible or robust. One of things I learned is that you can use ImageMagick to read and write comments into image files which got me thinking that you could store all of your metadata as an XML blob in the comments field. Which is pretty interesting since when you think about it a directory listing is basically a bare-bones slideshow. With some clever caching techniques you could simply attach a server based handler to a directory of images -- we'll ignore how you get the meta data in there for the moment -- and be done with it. Neat, huh? But I'm not a scholar on image formats and I don't really know what the rules are about one application respecting the comments that another application writes. And truth be told, I'm not that interested in learning. So, that means we're back to the stage where we've got a bunch of images and a bunch of XML files. Or maybe we've got just one XML file. Either way, we've got this funny bird that needs to be massaged before anything can be done with it. And writing any kind of DTD is going to be a pain because everyone is going to have some kind of random meta-ness they want added to their slideshow. Attentive readers (or David who got to listen to this rant, last night) will have begun to see where this is going:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" [
<!ENTITY % Slides SYSTEM
"http://www.aaronland.net/src/dtd/mod/xhtml/slide.mod">
%Slides;
]>
By redefining the XHTML %Block; and %Flow; entities, you can create a flexible slideshow format that is both XML fit for munging/transforming and HTML for easy viewing :
<!ELEMENT abstract (p*)>
<!ATTLIST abstract id ID #REQUIRED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #FIXED "Abstract">
<!ELEMENT slide (meta*,a)>
<!ATTLIST slide sid ID #REQUIRED
class CDATA #IMPLIED
style CDATA #IMPLIED>
<!ENTITY % Block "(abstract,ul)">
<!ENTITY % Flow "(slide)">
The ul (yeah yeah, it should probably be an ordered list...) element can only contain li elements. li elements are defined with the %Flow; parameter entity which means you can redefine your XHTML document to validate as a single list, that contains one or more items. Each item contains a "slide" which consists of zero or more meta tags (remember them?) and a link. If all your fancy pants server tools are broken you're still left with a list of named images that link to actual images. Not great but better than than an XML document rendered as a collapsible outline. So far, so good. But wait! There's more :
<Directory /path/to/image/directory>
DirectoryIndex index.html
SetHandler perl-script
PerlHandler Apache::ImageViewer
PerlSetVar ScaleSmall 25%
PerlSetVar ScaleMedium 50%
PerlSetVar ScaleLarge 75%
PerlSetVar ScaleThumb x50
<FilesMatch "index\.html$">
PerlModule AxKit
SetHandler perl-script
AxProvider Apache::AxKit::Provider::Filter
AxAddStyleMap text/xsl Apache::AxKit::Language::LibXSLT
AxAddProcessor text/xsl /site/xsl/slides/slide-tools.xsl
AxCacheDir /usr/local/www/htcache
AxDebugLevel 0
AxStackTrace Off
AxLogDeclines Off
AxNoCache Off
PerlHandler AxKit
</FilesMatch>
</Directory>
And while the example cited is mod_perl specific, there isn't much to prevent it from being implemented in whatever environment suits your fancy. All you need is a widget that can speak to ImageMagick and an XSLT engine that can suck in CGI parameters : sid and scale. Those are the keys used to 1) tell the stylesheet whether or not to render an image or an index and 2) tell the image widget which image to display and how big it should be. The next step is to write an XSLT stlyesheet to convert the XHTML described above in to an AxPoint document. download : slide-tools 0.1