Being able to easily render entities and collection of entities without any custom UI coding is great for being able to develop an understanding of the problem domain. However, it doesn't always make sense to let the user interact directly with the domain objects. For example, if the domain objects are very fine-grained such that clicking into them would be tedious for the user to do, it makes sense to introduce another object that collect the required data and walk the graph of domain objects on the users behalf. Or, more straight forwardly, the use case might be particularly complex or subtle, and we want to provide the user with additional guidance.

Wicket Objects therefore lets us work with objects designed to guide the user through the use case. Because they represent a particular solution to help the user achieve their objective, you can think of them as being part of the solution space (whereas regular domain objects belong to the problem space). Another name also given for objects of this type is "process objects"; they take the user through a particular process.

For example, we might have a wizard that takes the user through the process of making a new Claim:

The object this action returns is not a Claim, instead it is a ClaimWizard. Unlike Claim, this is not persisted; its state is bound to a particular users' session. The design of the ClaimWizard is like any other wizard, taking the user through a number of pages; first an introductory page:

After that we are taken through pages for each of the properties; For example the next page prompts for the Claim's claimant:

The Claim's approver and description properties likewise have the own pages, for example:

The final page allows the user to review details, then confirm:

On finish, the ClaimWizard will create and persists the Claim.

Process objects like wizards are primarily concerned with inputting data. We can also have objects that are tailored towards the output of data, eg for reporting. For example, we could have a (non-persisted) ClaimSummary object that sums up Claim amounts by Claimant:

We can then combine this with custom views, eg to represent a collection of such ClaimExpenseSummarys as a pie chart:

There's some guidance on writing application code to deal with such specialized use cases in Chapter 6, Supporting Specialized Use Cases.