It's that time again: say hello to Databinder 1.1 beta2.
Since the last beta, Databinder has learned an important new trick. Its Hibernate session factory is retained and managed by the client Wicket application object. This is accomplished through a new interface.
This system not only gets DataStaticService out of the business of having a static reference to one factory, it also allows for as many factories as the application class wants to manage. Each factory is associated with a key Object, which is set into Databinder models and providers through get/setFactoryKey. (Two things just occurred to me: maybe that should be an interface, too, and maybe the key needs to be Serializable instead of Object? Doh.) The default factory is used in any situation where the key is null.
The API changes very little for applications that stay with one session factory. They should continue to use the DataStaticService.getHibernateSession() utility function (or its keyed counterpart) to get the current session the way the model classes do. Those that extend DataApplication do not need to do anything differently. Those with independent application classes should implement IDataApplication and remove their calls to set the factory in DataStaticService (though it will still be able to retain the factory internally until the next beta). People that need multiple session factories can use the implementation in DataApplication or roll their own.
Here's the updated examples archive:
http://databinder.net/releases/examples ... .tar.bzip2
It has a Rakefile now (in addition to pom.xmls) for people using Buildr. And the release itself is available in modules at the central Maven repository (under http://repo1.maven.org/maven2/net/databinder/). The updated examples are the best way to get started on post-1.0 Databinder, if you haven't already.
That's it for now. There's some new UI components that I'll be writing about on Coderspiel, so look out for that if you are interested.
Nathan
