The batch validator, by default, recursively validates the content tree of the
EObjects that are presented to it for validation. However,
a model may not necessarily be hierarchically structured, but may have a flat or highly
cross-referenced structure. At its logical extreme, it may be normal for instances of a
model to be distributed across a considerable number of resources, even with just one
element in each resource. To support models like this, clients can define
traversal strategies to help the validator to discover the
graph of related elements to validate.
[
as SVG]
An
ITraversalStrategy
is basically an iterator, providing some additional context information and controls.
In fact, clients are encouraged to extend the
AbstractTraversalStrategy
class because it requires simply an estimate of the amount of work (for the progress monitor)
and an iterator that supplies the elements to validate, in sequence.
When the validation operation begins, the framework first calls the
startTraversal(Collection, IProgressMonitor) method, providing the
elements serving as roots of the traversal (e.g., the user's selection in the UI) and the
progress monitor. Then, the hasNext() and
next() are used in the usual way as for iterators to obtain
elements to validate. After each element is validated, the framework calls the
elementValidated() method, indicating the result of the element
validation in case that might influence the subsequent traversal.
The final consideration concerns
client contexts. With each
element that it provides, the traversal strategy is asked whether it is in a different
client context than the one before. This is the trigger for the framework to recompute
the client context, which can be a computationally expensive operation. In general, it
makes sense to recompute the client context when the traversal follows a cross-reference
(non-containment) but not when it follows a containment reference.
Using Traversal Strategies
An
IBatchValidator
can be configured with a traversal strategy. The framework provides two default implementations
as inner classes of the ITraversalStrategy class: the
Flat and Recursive strategies. The
latter traverses the content trees of the traversal roots, while the latter only returns
those roots without descending into their contents.
The default traversal strategy, where the client does not specify one explicitly, is a
composite strategy that delegates to implementations registered on the
org.eclipse.emf.validation.traversal
extension point. Where it cannot find a delegate on the extension point, it uses the
ITraversalStrategy.Recursive as a default.
<extension
point="org.eclipse.emf.validation.traversal">
<traversalStrategy
namespaceUri="https:///org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0"
class="org.eclipse.example.validation.traversal.EXTLibraryTraversalStrategy"/>
<eclass name="Person" />
<eclass name="Item" />
</traversalStrategy>
</extension>
This example shows an extension that declares a traversal strategy for the EXTLibrary
meta-model. It applies to traversals starting at Persons or
Items (rather than at libraries), perhaps because its purpose is
to back-track to the nearest containing Library and start from there. When traversal starts
from a Library, this extension indicates that the default strategy (recursion over the
containment tree) is sufficient.
Copyright (c) 2000, 2007 IBM Corporation and others. All Rights Reserved.