There are several frameworks that aim either to provide a back-end to Wicket and/or that aim to eliminate some of the boilerplate; notable examples are Wicketopia, Wicket RAD and DataBinder. There are also precanned archetypes, such as jWeekEnd's LegUp archetypes and IoLite, that do some of the wiring for back-end technologies like Spring and Hibernate. So, how does Wicket Objects compare to them?
Well, compared to Wicketopia for example, Wicket Objects shares the following ideas:
both frameworks support pluggable editors for Javabean properties
both frameworks allow the metamodel to be enhanced
declaratively using annotations (eg
@Length); these are picked up by the
editors
both frameworks support (or aspire to support) the metamodel being built from various sources, including for example Hibernate or JSR-303 annotations etc. In the case of Wicket Objects this is done by leveraging the underlying Naked Objects framework.
But there are some differences too; through Wicket Objects use of the Naked Objects underneath, it:
allows the metamodel to be enhanced imperatively as well as declaratively; naming conventions are used to associate supporting methods with the properties
supports user-defined value types (using Naked
Objects' @Value annotation);
important for domain-driven applications
supports three level of business rule (both declaratively and imperatively): is the entity class member visible, is it usable, is the value proposed valid. For most other frameworks, only the last of these (validation of proposed values) is typically supported
supports properties which are references to other entities, not just simple value types. In particular, Wicket Objects' property editor for references allows instances to be found by invoking repositories in-situ
renders entity collections as well as entity properties
renders entity actions (commands), allowing more than simple CRUD behavior to be exposed. Indeed, it's possible for the domain entity to be immutable except through the invocation of actions
The flip side of Wicket Objects' more
extensive metamodel support is that it uses Naked
Objects' own metamodel API. In contrast,
Wicketopia (only supporting properties and not
collections or actions) can get by using
java.bean.PropertyDescriptor from the
JDK.
Compared to frameworks and archetypes that use
Hibernate for the backend, Wicket
Objects (again by leveraging Naked
Objects) is more general here too. So, it has a
Session concept that is analogous to a
Hibernate session (and if using
Hibernate as a backend, the Naked
Objects' Session just wraps
Hibernate's). But it also supports other back-end
persistence stores too. Indeed, for rapid development we usually use
an in-memory object store.
Wicket Objects can also handle non-persisted objects as well as persisted objects; with every managed object is stored in an identity map. This support for non-persisted objects is important because it is central to supporting specialized use cases, including managing workflows for entering data, and dashboards for analyzing data.
A few other points worthy of mention:
Wicket Objects will automatically serialize both persisted and non-persisted objects, irrespective of whether the pojo itself is serializable. This is important if deploying on a cluster.
Through Naked Objects, every managed object also automatically has any domain service dependencies automatically injected into it),
Again, courtesy of Naked Objects, every persisted object has a unique, immutable and serializable object Id (OID). This can be a very useful resource when integrating with external services such as REST and ESBs.
Naked Objects also provides automatic dirty tracking, and optimistic locking.
Downsides? Currently Naked Objects does not support some of the Enterprise Java APIs such as JTA, so interactions with domain services that ultimately delegate to transaction stores (such as JMS) cannot be enlisted in the same transaction as the persistence store. And, obviously, it introduces a dependency on the Naked Objects framework over and above technologies such as Hibernate.
Aside from differences in capability, there's also a difference in philosophy.
Frameworks such as Wicketopia make it easy to render a form to edit the properties of an entity, but the application developer remains in control of the rest of the application service layer, and in wiring the various pages together.
In Wicket Objects, though, it is the
framework that is in control of this layer too, because the links
between pages are ultimately rendered by the property editor
Components provided by Wicket
Objects. and - in rendering the links representing
references - controls . What that also means is that every page
rendered by Wicket Objects is always of either an
object (typical case), or an action parameter dialog, or of a
collection (the result of invoking an action.
Within this constraint, there is a lot of flexibility, though,
because every element of the page can be customized. Internally
Wicket Objects uses the chain of responsibility
pattern to determine how which Component type to use to render a page
element. This works at a fine-grained level (eg a date editor) and
also at a larger-scale, (eg rendering a collection of
Locatable entities on a google maps). See Chapter 2, Application Walkthrough for more on this.
Wicket Objects is only one of a number of viewers available for Naked Objects. What that means is that you can take your same domain objects model and deploy them in other architectures. For example, the DnD viewer is a rich, desktop GUI that employs a drag-n-drop metaphor (hence its name). It can be run as a standalone single-user application or in client/server mode. Even if you don't deploy this viewer in production, the way that it displays domain objects makes for a very good development tool: something akin to a UML design tool, only animated.
Naked Objects also supports a number of different ways to test your application. Domain objects written to the Naked Objects programming model are just pojos, and so can easily be unit tested using frameworks such as JUnit and JMock. As a step up from that, Naked Objects provides a "headless" viewer that wraps your domain objects in proxies. This allows unit testing as if through the lens of a GUI; trying to invoke an action that is disabled will throw an exception.
Moving up to agile acceptance testing, Naked Objects has integrations with both FitNesse and Concordion. The business analyst can specify the behavior of the system in a wiki (FitNesse) or HTML (Concordion), and then the developer wire up this specification to the domain model using a set of fixtures that interact with the domain objects following the same rules as the viewers. This allows application-level testing without the hassle of using a GUI testing framework such as Selenium.
One final point: Naked Objects has a strong
separation between its programming model and the framework that
understands that programming model. So, your domain objects depend
only on the Naked Objects applib (which defines
annotations such as @RegEx), not the framework
itself. This allows you to take your domain objects and deploy them on
other frameworks later, if need be. You'll notice that
Wicket Objects continues this strong separation,
defining its own applib for annotations and features unique to the
Wicket Objects viewer.