Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Web development with Wicket, Part 3: Many ways to persist

Wicket adapts to your persistence needs, from conventional to unusual

By Nathan Hamblen, JavaWorld.com, 09/04/08

The best persistence technology to bundle with a Web framework might just be none at all. In this final installment in his series on Web development with Wicket, Nathan Hamblen demonstrates how Wicket's independence from any one persistence tool leaves your Web app with lots of options. See what happens when you persist application data in four different combinations of Spring, Hibernate, ActiveObjects, and Databinder.

According to the Wicket vision statement, Wicket was designed with the intentionally narrow focus of "enabling component-oriented, programmatic manipulation of markup." Of course, Wicket must account for requirements outside of that domain, such as data persistence, but it does so indirectly and flexibly, without incorporating any one solution. Wicket thus avoids two bugaboos common to other Web application frameworks: unchecked growth and unnecessary dependency.

Dependency here should be understood not only in its literal programming sense (a linked library), but metaphorically: a Web framework that ties its fortunes to a data persistence framework elevates its risk of an early decline. Today, Wicket is considered a fairly new, and thereby risky, option for Web development. If the project were to commit to a persistence framework, it would need to choose an established one to reassure users. But in the inevitable cycle of software growth, maturity, and decline, a safe choice early on would later leave Wicket with an outdated persistence technology. Decoupling from persistence eliminates that risk.

This series has been an overview of the benefits of of using Wicket for software development. I started with the machinations of software state in a stateless Web, then showed you how to leverage stateful components by aggressively reusing code and markup. This final installment will introduce you to practical approaches to data persistence with Wicket. Because there are so many ways to store data, we'll look at several permutations of an application. As the application evolves, you'll observe Wicket's interface with a progression of persistence technologies, from the familiar to the less so.

Example 1: Spring and Hibernate

You might be a Java programmer if seeing the words Spring and Hibernate together does not conjure images of a groggy bear emerging from a woodland cave. (And you might be a biologist if you point out that bears do not actually, metabolically, hibernate.) To most Java developers, a Spring-managed Hibernate session is an established persistence strategy. It's the first strategy you'll explore for building a data-driven Wicket application.

As most readers will have experience with the Spring and Hibernate side of things, this tutorial only covers the potential surprises. Firstly, for this application example you'll use Spring 2.5 and Hibernate Annotations. Doing so will reduce the bulk of XML configuration through classpath scanning and Java annotations. Secondly, the application will be self-contained rather than depending on a servlet container (see "Life outside the IDE" for a primer on how that works). While these departures make the application look different, they have no effect on the technique used to bring data to Wicket from Spring and Hibernate. You could use the same methods discussed here to integrate Wicket with an existing application using, for example, Spring 1.2, Hibernate Core, and a Tomcat JNDI data source.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.