Remember how it exciting it was when the graffiti demo made its first appearance? So audacious, so indifferent to the hegemony of gray 42-point Trebuchet MS.

Well that was nothing. It was static, two dimentional text. We can be far more offensive to HTML purists than that. We can use applets.

Click above, but you might want to open in a new window. The applet is half a meg, and we’re not friggin’ Akamai. This is offline for now. :( It’s hard to maintain as a separate build process, but maybe it will come back some day.

First of all, add a message. Please. Something besides random letters from the home row. Thank you.

What you’re seeing is 10% Databinder and 90% Processing, an alteration of the KineticType demo specifically. Processing is a Java environment optimized for graphical programming.

The Databinder webapp submits your message via ajax, adds it to the database (we’re good at that!), and then tells the applet (via JavaScript) to refresh its data using xmlrpclib. A small service class obliges, using Databinder’s Hibernate session factory to get the data and Apache XML-RPC to serve it.

This isn’t sprockets. That idea, as I understand it, requires a deeper integration between the applet and page components, so that you can use Swing components in a Wicket page without coding the applet itself, or writing out its tag. I still think that could be useful, but it isn’t appropriate for Processing, where half the fun is using the simple IDE for experimentation. It exports applet JARs in one click.

I wouldn’t mind having a Maven plugin to handle Processing source files, just to save me the trouble of copying the applet JAR (and keeping it in svn), but until then the build processes are separate. The only thing left to decide was how to communicate between the applet and the webapp.

One weird option is JavaScript. We’re already calling Java from JavaScript and we could be using it to transfer textual data to the applet instead of just signalling. It would be one fewer request to the server.

But the main reason I was doing this demo, aside from the coolness of swinging 3D text around, was to test Databinder outside a Wicket request cycle. And who knows how well Unicode, for example, travels across the JavaScript bridge? Better to use something a little more solid.

I considered Java RMI, one of those buzzy technologies everyone had to have on their resumes a few years back that is now practically forgotten. Though it didn’t appear to be the enterprise train wreck I expected, my exploration ended when I saw that I would have to run a server specifically to route RMI requests. Pshaaa…

Then I wasted some time with SOAP, which was going to bloat the applet to several megs, until I realized that good old XML-RPC does exactly what I need with less code. (That counts for a lot around here.)

The webapp source ended up being very compact, as it really doesn’t have much work to do. You’ll need the latest Databinder snapshot if you want to try this at home.

Or wait until 0.8 is out and a refined example is on the site. But don’t wait to add your wisdom to the database.

sdklsdaflkjalkd.