While the content of any given web page rendered by Wicket Objects is made up of multiple Components, there are in fact only a small number of WebPages:

Each of these has a corresponding HTML page which defines the content of that page. In many cases the look-n-feel of these pages can be adjusted simply using CSS, as described in Section 4.1, “CSS”. If necessary though an entirely different page layout can be specified, for example to put the menubar on the left rather than at the top.

The easiest approach to define a new page is to subclass PageAbstract superclass and then provide a different implementation of PageRegistry. As for ComponentFactorys, this is done by overriding a method in WicketObjectsApplication:

public class WicketObjectsApplication ... {
  ...
  protected PageClassList newPageClassList() {
    return new PageClassListDefault();
 }
}

As you can see, the default pages are specified by PageClassListDefault:

public class PageClassListDefault implements PageClassList  {

  @Override
  pulic void registerPages(PageRegistrySpi pageRegistry) {
    pageRegistry.registerPage(PageType.SIGN_IN, WicketSignInPage.class);
    pageRegistry.registerPage(PageType.SIGN_OUT, WicketSignOutPage.class);
    pageRegistry.registerPage(PageType.ENTITY, EntityPage.class);
    pageRegistry.registerPage(PageType.HOME, HomePage.class);
    pageRegistry.registerPage(PageType.ACTION, ActionPage.class);
  }
}

Do note though that if all you want is to provide a custom rendering of a particular interface or class, then you should instead write and register a ComponentFactory, with a ComponentType.ENTITY and filtering the EntityModel. The custom components described in Chapter 5, Custom Components do this, as does the component registered in the test application to render a wizard (see Section A.3.1, “ClaimWizardComponentFactory”).

As we've seen, you can also customize Wicket Objects in various ways by subclassing the WicketObjectsApplication bootstrap. The most common reason for doing so is to override the default implementation of ComponentFactoryList.

This design follows the general style of Wicket; in fact, you'll see that WicketObjectsApplication itself overrides a number of other methods (such as newRequestCycle() and newConverterLocator()), in order to hook Naked Objects into the rest of Wicket.

In general it's unlikely that you'll need to alter the behavior of these hook methods; but it's useful to know that Wicket Objects doesn't particularly interfere with the way in which you may be used to customizing regular Wicket applications.