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

Traversal Strategies

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.

Traversal Strategy API
[ 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.

         <eclass name="Person" />
         <eclass name="Item" />

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.

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