Ask and ye shall receive

Just poking around on the Blosxom website, and came across a link to Blapp which is a standalone blog manager for Blosxom.

It seems like it’s rather complete, but a wee bit rough – good enough, though. It also appears as though it will support exporting of the Blog to static HTML, so I can publish on .Mac.

Very cool.


Blap WILL publish a Blosxom site to any server, but it still requires Blosxom to be installed on that server. It doesn’t generate static HTML, but manages transfer of modified files to the remote blog location.

Blap is an open source project now, with a home on sourceforge


I’ve installed Bloxsom as my weblogging software. Installation went extremely smoothly, and initial customization went pretty well, too

I’m going to want to try to build a couple of things:

  • Calendar view
  • Search
  • Standalone blog entry tool

Other than that, it seems quite well done, and quite minimalist (good in this case – MT is overkill).

The one thing I don’t like about it that iBlog offers is the ability to publish static pages that can then be dumped on any web server (like .mac, or whatever). I use a TiBook as my primary machine, and if it’s not online, the blog isn’t available – for what I do that’s fine – nobody’s supposed to be reading this anyway, except me…

Services ROCK!

I was just poking around in the Services menu on MacOSX, and stumbled across the “Summarize” service. I’d seen it before, but never fired it up to see what it did.

What you can do is select any text in a Cocoa application, then hit the “Summarize” service. It will launch a mini app that will generate a summary of the selected text. You can even drag a slider widget to control the size of the summary (from complete, to very short). Extremely cool.

The abstract for this article was generated by the summarize service, on the body text of this article. It would be cool if iBlog could automatically fire off the contents of an entry to this service and transparently populate the Abstract field….

Malabsorbed Carbohydrates == Bad Juju

Evan has been horribly miserable for the last week. We started him on some Enfelac formula just to top him up before bed, and that seems to have backfired. He appears to have reacted badly to the formula – no bowel movements for a week, followed by an explosive (less than a second long, diaper exploding, ick…) one.

Good news is, he seemed a bit happier after, well, relieving himself…

This, of course, left us wondering what the heck was going on. Turns out there is a condition called “malabsorbed carbohydrate” where the little digestive system can’t fully process carbohydrates in the upper tract (stomach and small intestine), so they get passed to the lower tract (large intestine), where they ferment and produce a lot of gas. This explains the incessant farting, and apparent pain, followed by the mother-of-all-diaper-fillings.

We’re going to try switching back to 100% breastfeeding, and see if that makes a difference. He’s due for his 6 week checkup on Thursday, so hopefully everything will be resolved by then.

XSLT = XML the WO Way?

I need to be able to present a (potentially interactive) HTML page that is created from an XML file (such as an IMS, DublinCore, METS…). The way I had been doing it was with object modelling – convert the XML file into a set of objects, similar to EOs – relations and all – and then feeding those objects into custom WOComponents for display.

Turns out, there is a much better way. Simply create an .xsl file that contains the logic for each schema (or set of schemas, if similar enough), and just feed the results of the XSLT transformation into a single WOComponent. Very cool stuff.

This basically means that I can have themed metadata presentation (and navigation of content) without having to modify and java code. Customization can be done on the fly, by people who don’t have access to the source code.

I’ve got a simple test case where I convert any IMS record into an HTML page presenting the details about that record. Easy peasy. Next, to embed the transformation into a WebObjects application, and test it out there.

I’ve come across two challenges with this approach so far. First, the IMS schema (1.2.2) contains an invalid namespace, so java xml parsers choke when validating. I should be able to turn off validation once in WO. I’m using jEdit to create and test the .xsl file, so I don’t have access to the namespace property.

Second, most of the metadata schemas use the non-xml version of the VCARD specification. Unless I can figure out a way to process VCARD data within the XSL file, I may be hooped here. The Old Way, I just created a java class that understood the VCARD spec and ripped out relevant bits of data. I’ll keep plugging away at this…

Dynamic Customizable Components

So, I’ve been working on a way for the repository application to have customized “look and feel” – theming or branding – for various users. Turns out that the best way to do this totally destroys the Model/View/Controller design pattern. I’m basically mashing Model and View together, and using a single Controller for the combo.

Works great, though. I take the .html and .wod files and merge them together into a single .html string, which is associated with a component. This merged .html is then stored in a database, and called up when an appropriate request is made (theme matches, and component name matches). This .html string is then deconstructed into freshly minted .html and .wod files and fed into the standard WebObjects component handling mechanism, and a response is fed back to the user.





All are the exact same WO app (same instance, even), but the ?theme= parameter determines which merged .html combo string should be pulled from the database to generate the response.

VERY flexible. Too bad it breaks the WebObjects tools (WOBuilder doesn’t understand…)