Version 0.4 is available through the Maven repository and ready for to receive its public at databinder.net.

Want to see Wicket 1.2 beta2’s Ajax support acting on a database? All three Databinder examples have been glittered up with Web two-dot-oh. Join the party!

Having Ajax in Wicket’s core underscores the advantages of the framework in general. Real HTML templates with elements replaced by object-oriented code is the best way to program for the web.

With simple pages, the advantages may not be so obvious. But once you’ve built up a custom library of app-specific components or turned on the Ajax features, Wicket’s genius is plain as day.

Compare two “live search” implementations. Rails sets out to make it easy with helper macros explained on this wiki page. I did it in Databinder with a Panel subclass that requires almost no app-specific code, as seen in the phone directory example.

To be fair, the Rails implementation is more efficient than mine. I’m sending an Ajax request on every key-up event; they check for changes every half second. That’s a characteristic of a mature implementation, and Wicket’s Ajax will get there eventually.

What’s important to me is that we can eliminate the need to tell people “You must have one of [two macros] on your headers to have it working !!!” Wicket puts the needed scripts in the headers itself. And for the search results, Rails requires a special controller method ending with “render_without_layout” (whatever that means). But since we have Wicket as a (very smart) controller, we don’t have to write special rendering for Ajax requests.

Instead, we tell Wicket what components (wrappers, usually) should be rendered again when a certain Ajax event occurs, and it renders them exactly as it does for a normal request. Ajax, no Ajax, it’s the same code. When you submit a search form the old-fashioned way, you get identical results.

Through Ajax we’re earning bigger dividends from Wicket’s superior foundation. And don’t worry guys, it’s only going to get better.