Databinder at your (Web) serviceDatabinder at your (Web) service

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.

Codercomments

I considered Java RMI

Did you try Cajo?
It’s a 40K JAR (and this is if you use all of it).

Of course it’s smaller without the web server in the middle, but you can start RMI services from a servlet, if you want.

And it’s one line of code:

ItemServer.bind(new MyServer(), “MyServerName”);


Gustavo.

I should use Preview… what a waste of space!

Gustavo.

No worries, space is free here. Cajo looks cool.

Since RMI is included in the JRE (or isn’t it?) I could make a version of this with a smaller applet, without xmlrpclib. But then it wouldn’t run on older, or non-Sun, JVMs. As it is the applet should run just about anywhere, though I doubt it could hit 30 fps on an old processor.

Since RMI is included in the JRE (or isn’t it?)

Yes it is. I’m exposing JPA services through it. No XML, no HTTP, no web server.

Something I had to work out: for remote calls from the same client VM, sometimes the RMI server re-uses threads for performance. So you no longer have 1 request == 1 thread.

Gustavo.

Add a comment