|
|
|
|
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.
-
The extension point
org.eclipse.emf.validation.constraintProviders
is used to provide constraints. Static constraint providers declare constraints in the plugin.xml. Constraints are grouped into hierarchically
structured categories. Constraint providers target one or more EPackages by namespace URI. A group of constraints declares categories in which
they are members. Each constraint has a variety of meta-data associated with it (Language, ID, severity, mode, name, message, triggers, etc.).
Dynamic constraint providers address situations where constraints cannot be declared statically. e.g., where constraints are defined in models
or other resources. Dynamic providers declare a class implementing the
IModelConstraintProvider interface. This class is
responsible for making constraints available on the appropriate triggers, organizing them into categories, etc.
-
The extension point
org.eclipse.emf.validation.traversal
is used to provide customizable model traversal algorithms. Batch validation traverses a subset of the model starting from the user's
selections. No traversal is performed in live validation. Some meta-models require custom strategies for traversal. The default strategy
simply iterates the content tree via
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.
-
The extension point
org.eclipse.emf.validation.constraintParsers is
used to provide constraint parsing for languages. The validation framework provides support for two languages: Java and OCL. Clients can
provide support for other constraint languages via constraint parsers. The
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.
-
The extension point
org.eclipse.emf.validation.constraintBindings
allows clients of the EMF Validation framework to define "client contexts" that describe the objects that they are interested in validating,
and to bind them to constraints that they are interested in enforcing on these objects. A client context can declare an
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.
-
The extension point
org.eclipse.emf.validation.validationListeners
is used to define validation listeners for the validation service (
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.
-
The
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.
-
Clients can create an
EValidator
implementation
that delegates to the validation framework.
-
The framework provides implementation of an XML constraint parser (
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.
|
|
|