With
static and
dynamic
constraint providers populating the EMF Validation Framework with a vast library of
constraints for some selection of models, how does an application actually select the
constraints that it needs to get its job done? Other applications in the same Eclipse
environment may well contribute constraints that contradict its requirements.
Constraint bindings are intended to answer this need. On the
org.eclipse.emf.validation.constraintBindings
extension point, an application can define a client context that
identifies objects that it owns, and bind to it the constraints that it needs, either
individually or by category. Validation operations, then, will only evaluate the
constraints that are bound to the client context(s) matching any individual object.
Client Context Selectors
The definition of a client context is determined by a condition that selects the elements
that belong to it. This may be specified either using an XML enablement expression
(from the org.eclipse.core.expressions API) or by an implementation
of the
IClientSelector
interface.
[
as SVG]
The client selector simply computes a true result if and only if
it recognizes an object. This may apply conditions on the state of the object, the content
type of the resource that it is in, or anything else. For the XML enablement expressions,
the EMF Validation Framework does not supply any <with>
or <resolve> variables. However, any property testers
defined for model elements are available to assist in constructing the selector condition.
<extension
point="org.eclipse.emf.validation.constraintBindings">
<clientContext
default="false"
id="org.eclipse.example.libraryContext">
<enablement>
<test property="org.eclipse.example.resourceType" value="extlibrary"/>
</enablement>
</clientContext>
</extension>
The example above uses an hypothetical "resource type" property tester to check that an
element is contained in an EXTLibrary resource. Because this kind of computation can be
expensive, the EMF Validation Framework only computes the client context of
traveral roots, assuming that any objects reached from a root
during the traversal is in the same client context. By default, batch validation
traverses the entire content tree of every object in the initial selection, the traversal
roots. See the
Traversal Strategies topic for details of how to
customize the batch validator's discovery of elements to validate.
Binding Constraints to a Client Context
Having defined a client context, constraints are bound to it by ID. This can be done in
the same extension as that which defines the client context, or in a different extension,
even in a different plug-in. Constraints can be bound by category or individually, or in
a mixture of the two. Category bindings recursively include all nested categories. This
is particularly useful for dynamic constraint providers, where one or more categories may
be statically defined and nested categories created and populated at run-time.
<extension
point="org.eclipse.emf.validation.constraintBindings">
<!-- Simple binding to a single category -->
<binding
context="org.eclipse.example.libraryContext"
category="org.eclipse.example.library" />
<!-- Simple binding to a single constraint -->
<binding
context="org.eclipse.example.libraryContext"
constraint="org.eclipse.example.library.LibraryNameIsUnique" />
<!-- Simple binding to a mixture of categories and constraints -->
<binding
context="org.eclipse.example.libraryContext">
<category ref="org.eclipse.example.library/bookConstraints" />
<category ref="org.eclipse.example.library/writerConstraints" />
<constraint ref="org.eclipse.example.library.borrowerOverdueFines" />
</binding>
</extension>
Copyright (c) 2000, 2007 IBM Corporation and others. All Rights Reserved.