Databinder 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.
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.
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.)
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.