Many of the more advanced application configuration options will use properties to specify which java class should be used in a specific context, rather than hard-coding a specific class. This allows customised logic to be inserted into the application in various places. The properties used follow some common conventions that are described here. Though it is not necessary to understand this level of configuration entirely understanding these common conventions will hopefully make it easier to understand some of the more advanced configuration recipes outlined in this document.
classdef.name=fully-qualified-java-class A property of this form defines an alias for java-class that can be used elsewhere in the configuration files.
class-specification := [ classdef-name | fully-qualified-java-class ] Classdef names or fully qualified java class names can usually be used interchangeably.
class.name= class-specification A property of this form defines a plug-in or handler class. Usually the handler class is required to implement a certain interface or extend a particular super-class. Every database table in the application has a handler class and the usual convention is that a property of this form (where name is the name of the table) is used to define the handler class of that table. New tables can be added to the application by adding properties of this form and the behaviour of some of the standard tables can be customised by changing these parameters to point to a specialised version of the handler class. Not all properties of this form correspond to database tables however the same syntax is used for some other types of plug-ins as well.
class-specification-list := [ class-specification | class-specification-list , class-specification ]
table-name.composites = class-specification-list A property of this form defines a set of composite objects that are added to the database table handler class. This is a way of augmenting the behaviour of a table without changing any of the existing behaviour. For example if you want to add a field to the person table to track the gender of your users this can done by adding a GenderComposite to the person table. Composites usually operate on their own distinct set of database fields in the parent table. Composites register themselves as implementing a specific type that defines the capabilities of the composite. All composites registered with a database table handler class have to have distinct registration types. Adding a composite to a handler class will usually change the database table specification generated by that handler. If you add the composite before the table has been created the table will be created including all the fields needed by the composite. If you add a composite to the handler of a table that already exists then the database table will not be modified automatically instead the new fields will appear as options in the table editing forms.
class.TransitionProvider.transition-name = class-specification A property of this form identifies a plug-in that provides a set of “Transitions” which are a set of related forms operating on the same type of object. For example the application provides transitions to allow users to view and perform operations on the unix accounts that belong to them. If the web-page to perform an operation is at a URL /TransitionServlet/transition-name/* then it is a transition. This is another potential customisation point for the application as additional sets of transitions (or customised versions of existing ones) can be added to the application by setting parameters of this form.