On the road again

For a long time, I haven’t been blogging, partly because I really wanted a cross-posting with my own website, and was too lazy to set it up. I will be, therefore, courageous and just starting blogging again, as I have a whole number of ideas that keep bubbling up, and which I want to record somewhere to refer to later on. Tonight is blogging night.

Now that that is out of the way, man, do I wish I had some free time. My working life is pretty full, which, mind you, is a good thing, but the last few months I also wish I’d just had some time to hack on some open-source and personal soft-dev projects. I am already committed to two open-source projects, Flying Saucer and databuffer. DataBuffer has gotten no attention at all, have only had the chance to move the code from the original binding project (on SwingLabs) to its own home–and on Flying Saucer I’ve just been tending to the mailing list, and pointing people in the right direction when problems arise. Sadly, neither of these are really where my heart is at, though I believe that both of them are addressing problems that are core to the Java platform currently–and so there’s a conflict at hand, since the software/programming things I’d like to be working on all revolve around data–sharing, structuring, manipulating–so when I do have free time, I feel conflicted. I should, given my commitments, be working on those things I’ve committed to, but honestly, since I have so little free time, I’d rather be working on something else.

But I digress. Flying Saucer has been getting great attention lately, what with a killer article on java.netabout using FS to generate PDFs, SVG and images on the fly–I’d never thought of generating SVG with it, and I’ve been on the project for more than a couple of years now. We have a bunch of users generating images on the fly, generating XHTML on the fly, actually, then rendering to image formats. I’m hoping the mailing list will continue to thrive, and eventually, that we’ll get some more developers. Pete’s checked in some great work for our next release, R7, but we’re under-staffed right now, given what we want to accomplish and what we need to get done to make a real impact as a utility library.

I’ve been hacking around with two features–need to check those into a branch, actually–one is to support style-relative images (where images are embedded in CSS, and relative to the source/page of the CSS), and the other to support background image loading. Oh, and there’s also a cleaner model for handling XML namepaces via XMLFilters. For a long time, we’ve used NamespaceHandlers, which parse DOM Document instances already in memory for particular information–title, styles, legacy HTML–this new approach uses XMLFilters to accomplish the same thing. It’s much more readable, and once we have some generic filter classes we should be able to offer a much more robust approach to scraping important info out of incoming XML or XHTML.

The trick with these features is that they all require new relationships up and down the food chain–you need to know who owns the filters so you can attach them during the document parse, the image loader needs to notify someone as images are loaded (and the images need to be queued somewhere as you find them), etc. Actually, adding stylesheet information, to be able to track relative image references in CSS styles was kind of a hassle, because of how our current APIs for CSS are constructed (and for which I’m sadly to blame, having worked on many of them in the first place).

Hopefully, all of this will lead to improvements in the APIs. Historically, that’s been a truism of the project. We argue a lot about APIs and strategies and patterns and eventually come to an improvement. In this case, we need to clean up some of the ownership issues–like who owns filters, where the filters store what they’ve captured (assuming they are capturing filters), where images get queued, who’s responsible for creating form widgets, etc.

As for DataBuffer, well *sigh*. No time for it now. The current codebase is pretty good right now, as quite a lot of work was done on it in the last couple of years. The JavaDoc’s in good shape, for the most part. There are a lot of exciting possibilities once we get a multi-db testing framework in place to prove portability, and once we get some ease-of-use features coded, like auto-generated keys. For future development, I think we can do some rocking things around views using the decorator pattern aggressively. But first–time. Maybe around Christmas.

(Originally published as this JRoller blog entry)

This entry was posted in Uncategorized. Bookmark the permalink.