The validation framework provides support for constraint providers for any EMF meta-model (batch and live constraints), customizable model traversal algorithms, constraint parsing for languages, configurable constraint bindings to application contexts and validation listeners. The following are the main extension points and classes to be used with the validation framework.
IModelConstraintProvider
interface. This class is
responsible for making constraints available on the appropriate triggers, organizing them into categories, etc.
eAllContents()
API. Some meta-models do not use EMF containment relationships extensively,
or implement logical models on multiple distinct resources, making containment-based traversal impractical.
Language ID
: used in the lang
attribute
of constraint elements in the constraint XML. The Class
: identifies an implementation of the IXmlConstraintParser
interface, which constructs a constraint from the XML configuration data. Constraint parsers are responsible for parsing the content of a
constraint element in the plugin.xml to produce IModelConstraint
objects.
enablement
expression that matches model elements that are included in the context. Where that is not sufficient, an alternative
is to define a selector class using a selector
element. Client contexts can be bound to constraints, individually, or to
constraint categories (to bind all of the constraints in the category). Binding to constraint categories has the advantage of allowing new
constraint contributions in a category to automatically be bound to the appropriate client context, even if the constraint is defined in a
plug-in that is unaware of that context or its binding to the category. Category bindings are inherited by sub-categories from their
ancestors.
org.eclipse.emf.validation.service.ModelValidationService
).
The validation service will inform this listener whenever validation has occurred, loading it if necessary in order to do so. This is most
useful for cases where client plug-ins need to find out about validation events even before they are loaded. Otherwise, it is usually simpler
just to programmatically add a listener to the validation service. The value of the listener
element class attribute must be the
fully qualified name of a class that implements the IValidationListener
interface. Listeners can also be registered in code, at
run-time, using the ModelValidationService.addValidationListener()
method.
ModelValidationService
singleton coordinates the invocation of validation. It defines a single factory method for creation of
IValidator
for the batch and live evaluation modes. Validators validate one or more objects at a time; the kind of object
accepted as input depends on the evaluation mode. They can be configured to report constraint passes as well as failures, for verbose results.
Results are reported as IValidationStatus
. Validators can be reused by a client for any number of validation operations. The
ILiveValidator
validates EMF Notifications
. The IBatchValidator
validates EObjects
and,
due to its support for model traversal, supports progress monitors. Registered traversal strategies can be overridden by the client.
EValidator
implementation
that delegates to the validation framework.
org.eclipse.emf.validation.xml.IXmlConstraintParser
) API
that supports definition of XML constraints in OCL. The class OclConstraintParser
is the constraint parser
implementation that creates instances of the OclModelConstraint
class, the OCL-language constraint implementation,
from XML constraint descriptors. It uses the Query
class to test model elements against an OCL constraint expression.
Please refer to the tutorials Validation Tutorial, Validation Adapter Tutorial and OCL Validation Tutorial for reviewing some code samples.
Copyright (c) 2000,2005 IBM Corporation and others. All Rights Reserved.