The controller layer is based around a controller-per-resource
pattern, so there are controllers for taxa, names, references,
specimens, descriptions, agents, terms etc. In addition there is a
smaller number of supporting controllers. These controllers are
stateless and use Spring MVC, in particular, the annotation-based
controller configuration. At the moment the controllers map to uris that
end with *.do but in the short/medium term the
controller layer will be refactored to conform to a more RESTFul
approach, and will aim to conform with the CDM REST
Service 2.0 API.
In addition to using stateless controllers for serving requests for data, CATE uses the Spring Web Flow API to allow users to edit data by following non-linear paths between related data items. As with many things in CATE, the flows are modularized into a flow-per-resource, with flows launching subflows when a user wants to edit a related item without committing first. Currently there is no pessimistic locking of data. This may have to be implemented in the future.
The controller layer does not, in general use separate data
transfer objects (DTOs), instead using property editors to bind data in
a request to CDM model objects. This is not always very easy, but leads
to a much simpler situation overall as there are no DTO's to keep in
sync with the domain model. CATE currently uses a couple of custom
interceptors to apply global behaviour to the web requests. One is a
ContentNegotiationHandlerInterceptor, which is
likely to be replaced with the standard spring
ContentNegotiationViewResolver. The second is the
AuditEventContextHandlerInterceptor that sets the
audit event context based on a parameter in the request
(view) if present, or retrieves it from the
session, if it exists, or sets it to the current view, if all else
fails.
Being the primary entry point for data into CATE there is also some data validation logic in this layer. This is likely to be ported to the CDM Java Library as part of an upcoming contract.
The view layer in CATE is also based on Spring MVC, and uses
Apache Tiles and Apache Velocity to render content as HTML. In general,
CATE tries to return a single object, or a couple of objects per
request. For the HTML pages, several objects are usually needed to
populate the navigation bar etc, and these are retrieved using a Tiles
ViewPreparer. There is some caching of
this content for eficiency. Also there is a customized
VelocityToolboxView that inserts objects from the
spring applicationcontext into the velocity context as tools.
The controller layer is mainly configured using annotations, but a
few beans are declared using XML in
cate-controller/src/main/resources/org/cateproject/controller/applicationContext.xml.
The view layer is configured using
cate-view/src/main/resources/org/cateproject/view/applicationContext.xml
plus views.xml from the same directory. There is a
standard cate-project theme, plus cate-araceae and cate-sphingidae
specific themes in themes, Apache Tiles definitions
in tiles, and velocity templates, layouts and
macros in velocity. The static files (images and
css) are in cate-view/src/static.