Home > Tutorial

Define Advanced Constraints

We just went through the definition of every element corresponding to each table in the database. Our modeling task is not ended at this point, as we need to enrich the model with extended functionalities that XML Schema does not natively support.

Extended facets

XML Schema gives the opportunity to specify constraints (a.k.a. facets) on the schema elements. This gives the opportunity to implement business logic across the schema elements and ensure the coherence and integrity of the relationship between elements.

All extended facets are declared under an osd:otherFacets element.

Foreign key constraints

We just learned how to implement the primary keys for all table type elements in our schema. A reference to a table (foreign key) is defined using the extended facet osd:tableRef . This element is defined under the element xs:annotation/xs:appinfo/osd:otherFacets .

As a child of the facet, we may specify:

• container : reference of the instance that contains the table. Default is current instance,

• tablePath : XPath expression that specifies the table (required),

• display : XPath expressions or programmatic renderer that specify the composition of the label (default is the primary key),

Example: Ensure that element pub_id in table Titles refers to element pub_id in table Publishers .

See also:

• Foreign key definition

Dynamic constraints

We can easily specify that the value of element lo_range in table Royalties must be higher than 1:

However, this kind of constraint is static in the declaration, preventing to express constraints between elements.

EBX.Platform provides additional constraints that are not specified in XML Schema, i.e. dynamic constraints. A dynamic constraint is declared on an element, referencing another one, which is semantically linked with it. The two elements are then dynamically compared at runtime, and each time the constraint is breached, an error message is triggered.

Like any other extended facets, the constraint is declared within an xs:annotation/xs:appinfo/osd:otherFacet element.

The osd:otherFacet keeps the same semantic as the xs:restriction element used for static constraints:

• the constraint type is not in the xs namespace anymore, but in the osd namespace , 

• all constraints types have their equivalent (minInclusive, minExclusive, maxInclusive, maxExclusive, minLength, maxLength, length), depending on the element type.

Example: Ensure that lo_range value is always lower than hi_range value in the Royalties table.

We implement a dynamic constraint on the lo_range element, referencing the hi_range element.

As displayed in the following EBX.Manager screenshot: when the user submits a lo_range value higher than the hi_range element, a default error message is raised ("the value is too big").

The error message is customizable in the schema under the osd:otherFacets element, using the osd:defaultErrorMessage element.

The message can be localized and customized for the user need.

See also:

• Dynamic constraints definition

excludeValue Constraint

EBX.Platform also provides extended facets aimed at preventing a specific value for an element.

The osd:excludeValue element is dedicated for that purpose. It accepts a value as an attribute, which specifies the reject value for the element.

Example: Ensure that lo_range value is different from value "1" in the Royalties table .

See also:

• Exclue value constraints definition

excludeSegment Constraint

Following the same principle as the excludeValue constraint, the excludeSegment element prevents the element value from being out of the specified range.

Please note that the boundaries of the range are excluded.

Example: Ensure that lo_range value is out of range (100,200) in the Royalties table.

See also:

• Exclude segment constraints definition

Resource constraint

It may sometimes be useful to declare an external resource in the model. For instance, an image or HTML resource can enhance the look and feel of an instance screen in EBX.Manager.

In our sample database context, we could add a field called front_picture in table titles that refers to an image, i.e. the front page of the book.

This can be done easily, using the osd:FacetOResource .

Please note about the osd:FacetOResource attributes:

• moduleName : indicates with an alias which EBX.Platform module contains the resource. If it is the module itself that contains the resource, the alias must be preceded by "wbp" (stands for Web Business Process). Otherwise, the alias must be one of the values defined in the element <dependencies> in file ‘module.xml’

• resourceType : resource type is one of the following values: "ext-images", "ext-jscripts", "ext-stylesheets", "ext-html"

• relativePath : A local directory where the resource can be found, just under the "resourceType" directory (here www/common/images ). Hence, for this example, the resource is located at www/common/images/frontpages/ where the www/ directory is at the same level as the WEB-INF/ directory.

See also:

• Resource definition

Next: Develop Programmatic Constraints >

Home > Tutorial