Chapter 5. Custom Components

Table of Contents

5.1. About the Components
5.1.1. Common Layout
5.1.2. Update Classpath
5.2. Gmap2
5.3. Google Charts
5.4. CoolDataSoft Application Services Menu

Abstract

This chapter describes a number of custom components for Wicket Objects. Some of these integrate third party components and/or experimental.

As was described in Section 4.2, “Component Factories”, the Wicket Objects viewer is designed to be extensible, allowing you to plug in more sophisticated renderings of the domain objects that make up your application. This chapter describes a number of custom components that demonstrate this capability, most of which are basically wrappers around functionality within the Wicket's companion WicketStuff project.

The components here are probably best considered as examples rather than formally part of Wicket Objects, if only because we want Wicket Objects to depend just on core Wicket, not WicketStuff. But what you will find is that all the components here follow a similar layout, so you can easily adapt copy them into your own projects and adapt them as you feel fit.

5.1. About the Components

The source for these components is available at https://wicketobjects.svn.sourceforge.net/svnroot/wicketobjects/trunk/views.

5.1.1. Common Layout

Most of the components define their own interfaces or annotations; these are then implemented or annotated on the domain classes so that the component knows whether it applies or not (see discussion on ComponentFactory, in ???).

To minimize the coupling between the domain objects and the component implementation, we separate out the interfaces/annotations into an applib.

The naming convention for these modules is:

  • org.starobjects.wicket:view-xxx for the parent module for view 'xxx'

  • org.starobjects.wicket:view-xxx-applib for the applib submodule

  • org.starobjects.wicket:view-xxx-view for the view submodule (that contains the actual ComponentFactory and Component implementations)

5.1.2. Update Classpath

The classpath for both the dom submodule and the commandline / webapp submodule each need to be updated (see Section 3.1, “Structure of a Naked Objects Application” for an overview of the typical structure of a Naked Objects application):

  • the dom submodule should be updated to reference the view-xxx-applib submodule for each custom component

  • the commandline / webapp module should be updated to reference the view-xxx-view submodule for each custom component