This is the beginning of a series that is to become Databinder 101, an introductory text for the toolkit.

The heart of Databinder is the HibernateObjectModel. It’s where Hibernate meets Wicket to transparently load and persist data reflected in the user interface. Understanding how it works will put you on your way to smooth Databinder programming.

IModel

Before delving into the HibernateObjectModel class, let’s go over the IModel interface it implements.

As is the trend in GUI frameworks (e.g. Cocoa Bindings), Wicket binds UI components formally to the data they represent. You might think that a component could reference a plain object as its model and be done with it, but there are several ways the IModel middle-man earns its commission.

Firstly, it allows the actual model object to be an imaginary projection. Instead of assigning an object to all child components, you often benefit from a CompoundPropertyModel assigned to a root component. This root model handles model requests for its child components with no models. Their wicket:id values map to properties of the root model object implicitly.

This same idea can be taken in unusual directions, like our SublistProjectionModel. It’s also common to have anonymous-subclass models that combine or operate on data to build model objects on the spot. These things wouldn’t be possible without a model container standing between components and their model objects.

The other purpose of IModel is detachability. We can’t always toss plain objects between Web requests. Some objects are just too big to be retained for each user of a busy Web application. And some objects—all Hibernate managed objects—are associated with particular database sessions and need help to go between two. Custom IModel implementations, such as Databinder’s, handle persistence of component data, allowing Wicket component classes to remain storage-generic.

To be continued…