Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse EMF Validation Framework
Previous Page Home Next Page

EMF Validation Framework Overview

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Clients can create an EValidator implementation that delegates to the validation framework.
  8. 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.


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire