<!ELEMENT extension (clientContext* , binding*)>
<!ATTLIST extension
point CDATA #REQUIRED
id CDATA #IMPLIED
name CDATA #IMPLIED
><!ELEMENT clientContext (enablement | selector)>
<!ATTLIST clientContext
id CDATA #REQUIRED
default (true | false)
>Definition of a client context, representing a class of objects that a client wishes to apply a set of constraints to.
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.
<!ELEMENT selector EMPTY>
<!ATTLIST selector
class CDATA #REQUIRED
>A selector determines which model elements are included in a client context when an XML expression is too cumbersome or somehow not sufficient to implement the test.
org.eclipse.emf.validation.internal.model.IClientSelector
internal API interface.<!ELEMENT binding ((category | constraint | extendClientContext | excludeCategory | excludeConstraint)*)>
<!ATTLIST binding
context CDATA #REQUIRED
constraint CDATA #IMPLIED
category CDATA #IMPLIED
>Declares a binding between a client context and one or more constraints. The context can, itself, be declared by the same plug-in or by a different plug-in.
The constraints to be bound may be specified by either:
constraint
attribute, to reference
a single constraintcategory
attribute, to reference
a single constraint category and all of the constraints
that it includes<constraint>
and/or <category>
elements to
reference multiple constraints and/or categories
Since the 1.3 release, selective exclusion of constraints and sub-categories that are contained by included categories is supported. Within a <binding>
element, ordering of inclusion and exclusion elements is significant: they are processed in the order in which they are declared in the extension. However, the order of inclusions and exclusions in separate bindings for the same context is undefined.
category
attribute.Identifies a constraint category to be bound to the client context. The referenced category and all of its constraints, sub-categories, and their constraints are bound.
This attribute may not be used in conjunection with
the constraint
attribute.
<!ELEMENT constraint EMPTY>
<!ATTLIST constraint
ref CDATA #REQUIRED
>
Includes a constraint in a client context
<binding>
.
<!ELEMENT category EMPTY>
<!ATTLIST category
ref CDATA #REQUIRED
>
Includes a constraint category in a client context
<binding>
. All of the referenced
category's constraints and those of any sub-categories
(recursively) are included.
<!ELEMENT extendClientContext EMPTY>
<!ATTLIST extendClientContext
ref CDATA #REQUIRED
>
Since 1.3. References a client-context that the bound context extends. Conceptually, this declares that objects matching the referenced context also match my bound context. In practice, this means that my bound context inherits all of the constraint bindings from the referenced context.
Of course, subsequent exclusions can filter out unwanted constraints, too. Note, also, that this effects a dependency on the referenced client context and also imposes a partial ordering on the bindings. All of the bindings contributed to the referenced context are applied before any inclusions or exclusions that follow the <extendClientContext>
element in the current <binding>
.
<!ELEMENT excludeCategory EMPTY>
<!ATTLIST excludeCategory
ref CDATA #REQUIRED
>
Since 1.3. Excludes a constraint category from a client context
<binding>
. All of the referenced
category's constraints and those of any sub-categories
(recursively) are excluded. This is useful when including some parent category, to filter out selective sub-categories. Not only is it simpler than explicitly including all of the desired sub-categories, but it ensures that sub-categories that are added later will be included implicitly.
<!ELEMENT excludeConstraint EMPTY>
<!ATTLIST excludeConstraint
ref CDATA #REQUIRED
>
Since 1.3. Excludes a constraint from a client context
<binding>
. This is useful when including some parent category, to filter out selective constraints cointained within it. Not only is it simpler than explicitly including all of the desired constraints and sub-categories, but it ensures that constraints and sub-categories that are added later will be included implicitly.
Example of a context which includes EObjects
in *.library resources only, not
in some other kind of resource that uses the EMF Library example meta-model (utilizing an
hypothetical property tester):
<extension point="org.eclipse.emf.validation.constraintBindings"> <clientContext id="com.example.MyClient"> <enablement> <with variable="resource"/> <test property="com.example.matchURI" value="*.library"/> </with> </enablement> </clientContext> </extension>
Example of a binding of a single constraint to the MyClient context:
<extension point="org.eclipse.emf.validation.constraintBindings"> <binding context="com.example.MyClient" constraint="org.eclipse.uml2.validation.classifiers.genCycle"/> </extension>
Example of binding multiple constraints and constraint categories to the MyClient context:
<extension point="org.eclipse.emf.validation.constraintBindings"> <binding context="com.example.MyClient"/> <constraint ref="org.eclipse.uml2.validation.namespace.distinctMembers"/> <constraint ref="org.eclipse.uml2.validation.classifiers.genCycle"/> <category ref="uml2/spec/classes/kernel/namespaces"/> <category ref="uml2/spec/classes/kernel/classifiers"/> </binding> </extension>
Copyright (c) 2005, 2008 IBM Corporation, Zeligsoft Inc., and others.
All rights reserved. This program and the accompanying materials
are made available under the terms of the Eclipse Public License v1.0
which accompanies this distribution, and is available at
http://www.eclipse.org/legal/epl-v10.html