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
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

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




Eclipse EMF Validation Framework
Previous Page Home Next Page

Binding Constraints to Applications

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.

Client Context Selector API
[ 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.

            <test property="org.eclipse.example.resourceType" value="extlibrary"/>

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.

      <!-- Simple binding to a single category -->
            category="org.eclipse.example.library" />

      <!-- Simple binding to a single constraint -->
            constraint="org.eclipse.example.library.LibraryNameIsUnique" />

      <!-- Simple binding to a mixture of categories and constraints -->
         <category ref="org.eclipse.example.library/bookConstraints" />
         <category ref="org.eclipse.example.library/writerConstraints" />
         <constraint ref="org.eclipse.example.library.borrowerOverdueFines" />

Copyright (c) 2000, 2007 IBM Corporation and others. All Rights Reserved.

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