# 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.

> [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.