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…


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…

Blapp Links

I know this is on the Blapp homepage – there’s even a screenshot of it working – but I never tried it out until now.

Dang, that Links window is cool! It scans all blog entries for hrefs, then presents a simple interface to list and search them, so you can reuse previous links. Well done. Dragging an item from the Links window into a new blog entry even generates the appropriate HTML element. Slick.

Now, wouldn’t that searchability be a nice addition to the Safari Bookmark Manager?

Blapp – Blosxom Blog Editor

I’ve been using Blapp for a while now to manage the entries for this blog. It’s pretty cool, and I just saw that Michael McCracken now has a badge for his cool software.

Anyhoo, here’s credit where it’s due: Blapp

It’s good to see that Michael plans on continuing development of Blapp, even though NetNewsWire Pro will have integrated blog edting. I like Blapp, it’s a neat little program. Could use some tweaks, but it’s not bad at all. Oh, and it’s free, which is a Good Thing.

Here’s a couple things that would be nice if added to Blapp:

  • Auto-entry-filenames. NNWP has this, and it’s quite useful for when you can’t immediately think of a unique filename (what else is in the directory? Have I used this name before? …)
  • Some form of WYSIWYG editing. Sure, it’s fun (fun?) to edit raw HTML, just like our grandparents did, but sometimes it’s just plain annoying. update: must be getting rusty – I had to re-edit this entry 3 times to get the HTML right. Doh.
  • Option to re-wire the function of “Publish”. I have the dynamic blosxom blog script on my TiBook, and a static rendering on my .Mac account. Publishing, in my case, means calling a perl script with a couple of parameters to update the static blog rendering, rather than just copying new entry .txt files to another directory.
  • Better HTML preview. I know this would be best done using the Safari SDK when available. Worth waiting for. It’s irritating seeing images go from thumbnail to image display and back again with each keystroke while editing an entry (like the Blapp badge is doing right now. stop it. no, really. stop it. grrr…) I’d even settle for a static preview that I have to manually update (like Dreamweaver has) – that would hopefully prevent the attempted rendering of incomplete HTML elements.

Anyway, Blapp is just plain good software. Thanks, Michael, and keep up the great work!

update: added the http:// prefix to the blapp href.

Blosxom 1.0

I’ve just “upgraded” to Blosxom 1.0, and it was (of course) a smooth process.

Congrats, Rael, on hitting the mythical 1.0!

I finally figured out where to modify blosxom.cgi so that it doesn’t render the entire freaking blog with each static rendering of the site… Easy change in line 167, to remove the first condition (if dynamic, pay attention to the entry count limit) – after removing that condition, all pages will obey the entry count limit.

Update: Well, that didn’t work so well… Fixed the post-every-entry-to-the-.html-flavour problem, but munged the xml feed. Doh.

Blosxom 1.1 revisited

Looks like it’s working properly now. Not sure why it was acting up before, but it looks like Operator Error (code ID 10 T, most likely).

Thanks to Rael for double-checking my copy of the blosxom.cgi file, to rule out any kind of serious problem.

I’ve now limited the number of entries on each page to 15, so it’s not a 50K hit each time. There’s also a category index on the left side now, as well as indices for each category (just change the index.html URL to index.index, and you’ll get a list of entries).

I also modified my xml feed to wrap the entry text in CDATA, so it parses and validates properly for entries that have HTML in them.

iCommune speculation is misdirected

This is just my take on it, but I’ve just about had my fill of the “Apple is Evil” rants regarding their actions toward the developer of iCommune.

It seems like a clear-cut case: iCommune violates the device-plug-in-API license agreement. It has NOTHING to do with what iCommune does. Apple isn’t saying “you can’t do that”, they’re saying “you can’t do that with that API”.

They have a history of doing this kind of thing especially around APIs that are either half-baked (i.e., incomplete, not half-assed), or on the way out (planned deprecation), or about to be superceded by something better.

While I think iCommune sounded cool (although I never checked it out), I’m willing to give the Mothership the benefit of the doubt. I certainly don’t have the whole story, and these online APPLE IS EVIL rants don’t add to it.

I’m more than happy to wait for the rendezvous-enabled update of iTunes3, and let this rabble die down until then.