My first iMovie

Wow. That was easy. (of course). Not having a digital video cam, I brought in a bunch of photos from iPhoto, and a track from iMovie, and used the famous Ken Burns Effect to make a slide show.

Went pretty easily. MUCH faster than the old way I used to do this. Several years ago I had to do a couple of slide shows, and used Director and Premier. The result was effective, but consumed about 2 weeks of my spare time. That sucked.

With iMovie, I did the same thing in about half an hour. Including the time it took to export a quicktime for use on my .mac homepage…

I didn’t take the time to fiddle with the KBE, so it’s the stock generic zoom-into-the-middle-of-the-image pan, which isn’t ideal for some of these images…

Anyway, check it out here.

Webobjects Theming: XML to HTML + WOD

Woohoo! I just got an XSLT prototype working that will let me re-implement theming in our repository application!

My goal was to produce a solution that would allow (some of) our users to completely customize the interface of our WebObjects application, in a way that simply mucking about with the .html part of a WOComponent simply couldn’t support. They need to be able to add/remove/move/modify functionality that may not be predetermined in a .wod file.

So, what I did was to produce an XML-based format to store combined data from what would have conventionally been stored in separate .html and .wod files (I know, breaking MVC, but so what – it does what we need). This XML file can be edited in anything that can edit XHTML – like, say, Dreamweaver…

The cool thing about this “theming engine” is that it allows a form of inheritance on the customized components. If a theme of our application only needs 1 or 2 modified components, then you only have to add new database records for those modified components, edit a couple of XML strings, and you’re done. The rest of the theme will be automatically inherited from the default theme (I’m also wanting to allow users to specify WHICH theme they inherit from. That could be REALLY powerful).

If you want to completely change the look of the app, you’re free to do it. All you need is 1 XML string/file/record per WOComponent being customized.

Basically, I take the XML string, feed it into my XSLT translations and pump out the conventional .html and .wod strings, which will be cached in the database so it doesn’t suck performance-wise.

When the XML source strings are updated, they’re run through the XSLT translation again and the cache is updated. The cool part about the way this will be cached is that it is persistent across applications and instances – the cache is stored right next to the XML source in the repository application database.

I’m actually quite hopeful that this will work out, since it will let our partners hack away on the interface without having to learn WebObjects (or how to compile an application), or the structure of a PLIST file, or whatever… They should be able to happily pump stuff out of Dreamweaver (or BBEdit, or JEdit, or whatever), and feed it into the theming engine. All we have to do is document the WOComponent library that is available to them (classes, attributes, what it does, etc…)

Now, to prototype it actually working in a WebObjects app…

jEdit

I’ve been using JEdit for a while now, and am constantly amazed at how complete it is. It’s even got a plug-in to manage XSLT transformations… Not as elegant as I’d usually like, but the integration into a kick-ass editor more than makes up for it.

WIth the addition of the Project Manager plugin, it’s pretty full-featured, and the somewhat sluggish Java UI is still very usable (even on a pokey TiBook 400! (one aside on the Project Manager plugin – it seems to require Java 1.4.1 to install, but if you run JEdit once under the 1.4.1 prerelease, you can install the plugin and it still works under 1.3.1…

I’ll retire Optimus Prime (and TestXSLT) for now and focus on JEdit and XSLT (which uses Xalan-J etc…) since it provides some rapid turnaround between editing XML, XSL and viewing output. I’ve set it to generate output.html in ~/Sites/ so I can bookmark it in Safari and reload as needed.

Optimus Prime – XSLT Transformation App

I’m working on a simple java application to manage transformations using XSLT via Xalan-J. Not sure if I’ll use Cocoa-Java or SWING. Don’t care a lot about cross-platformability, since it really only has to work on my machine…

I don’t have a lot of experience with SWING (did a simple app a couple of years ago), and have no experience with Cocoa, so I’m kinda ambivalent (although having an excuse to learn Cocoa would be cool, I’m not sure I have the time to take that on). Since I have a brain-dead-simple command line Java app working already, I might just do it in SWING.

Actually, the command-line version works just dandy, but doesn’t have the ability to remember state – which source xml file to use? which xslt? where to put the output? any parameters? open output in another application? which one? …

Update: It seems as though Marc Liyanage has beaten me to the punch with TestXSLT. It seems like it’s almost exactly what I was planning on building. Thanks for saving me some time, Marc! He’s even released the source, so I might be able to tweak if needed. Cool.

I’ll be playing around with TestXSLT (and his BBEdit XSL vocab) over the next couple of days. Should be interesting…

Update 2: It looks like the 2 XSLT libraries used in TestXSL (Libxslt and Sablotron) handle xsl:import and xsl:include differently than Xalan-J – that is they appear to fail with relative URIs… Not sure what’s causing this, but it’s not too fatal (yet)

Update 3: Marc has an older version of TestXSLT that he wrote in Java, and which uses Xalan-J, so for testing stuff out in the _real_ xsl library, there’s a tool there. It’s not as polished as TestXSLT 2.5, but it’s better than command-line. I might try to graft a Xalan option into TestXSLT 2.5 using the Cocoa-Java bridge…