Constraint files

In order to simplify the validation logic implementation, we use the Hibernate library to help framework providers/managers define validation rules in constraint files (see Figure 6-9). Hibernate requires constraints to be defined in XML format, which is then processed by the API (described in Section 6.3.2) to perform the validation. The validations can be extended quickly without developing new application code. Framework providers/managers can add or modify rules in the XML file to address different requirements.

Figure 6-9 shows constraints defined in XML for the base class Sample <!-- Base class constraints -->

<bean class="Sample"> <getter name="name">

<constraint annotation="javax.validation.constraints.NotNull">

<message>ERR: Sample name is required</message>

</constraint> </getter>

. . . </bean>

Figure 6-9 Constraint file for base class Sample

 Getter Name: defines which attribute is going to be checked (name in the Sample class in this case). The API will use the class get method (e.g. getName) to retrieve the attribute value to check.

 Constraint: defines the validation constraints, e.g. NotNull in order to make sure the end user has supplied the required sample name

1

2 3

62

 Message: a message can be defined here to inform end users a sample name is required.

 Constraint Inheritance

The rules defined in the base classes will be inherited by all the individual level classes. For example, a Not Null constraint is defined to check the sample name in the base class; the constraint will be automatically inherited to individual level (via the organisational class) to make sure all samples names are required.

The organisational and individual level constraints are also defined in the same constraint file (see Figure 6-10). Validation rules in the organisational level should be applicable for all users within the particular organisation. For example, the sample location must be provided at PFR. A NotNull constraint can be defined at the organisational level in order to ensure all individual level samples have location information.

At the individual level (e.g. Onion Sample), all validation rules from the base and organisational level are inherited and specific validation rules can also be added, e.g. a constraint for attribute singleOrBulk (see Figure 6-10). A regular expression is used to check the value must either be Single or Bulk. In addition, more constraints can be added in the individual level to check different types of samples, e.g. Apple or Orange.

Constraints are combined if multiple constraints are defined for the same attribute at different levels. For example, if a specific constraint (e.g. the sample name must be between six and ten characters) is defined at the individual level, it will be checked in addition to the NotNull constraint defined from the base sample class.

63 <!-- Base class constraints -->

<bean class="Sample"> . . .

</bean>

<!-- Organisational level constraints -->

<bean class="PFRSample">

<getter name="location">

<constraintannotation="javax.validation.constraints.NotNull"> <message>ERR:Sample location may not be null</message>

</constraint> </getter>

. . . </bean>

<!-- Individual level constraints -->

<bean class="Onion">

<getter name="singleorBulk">

<constraint annotation="javax.validation.constraints.Pattern"> <message>ERR: the singleOrBulk must be

Either single or bulk</message> <element name="regexp">Single|Bulk</element> </constraint>

</getter> . . . </bean>

Figure 6-10 Constraint file for the entire Sample hierarchy

 Cardinality Constraints

A many-to-many relationship between the Sample and Assay was implemented to maximise the database flexibility. In some cases, a particular assay only tests one plant sample, in other cases it might test more. In order to control the cardinality, a constraint can be defined to limit the number of elements in the mySamples collection of the assay class. The generic validation code will check whether the number of samples matches the predefined constraint rules. For example, the cardinality constraint in the class OnionAssay (shown in Figure 6-11)

demonstrates how to restrict the number of samples in the OnionAssay Object. The constraint is used to make sure that OnionAssay must have at least one and not more than three

associated samples.

<bean class="OnionAssay"> . . .

<getter name="mysamples">

<constraint annotation="javax.validation.constraints.Size"> <message>ERR:An assay can only test between 1 and 3

64 <element name="min">1</element> <element name="max">3</element> </constraint>

</getter> . . . </bean>

Figure 6-11 Cardinality Constraint

Domain objects and validation rules can be defined in ORM and constraint files but maintaining these files requires learning specific mapping syntax. In order to make the definitions even simpler, we provided a single text based configuration template to help framework managers customise their individual level domain objects and validation rules. The configuration template will be described in Chapter 7.