diff options
Diffstat (limited to 'docs/org.eclipse.wst.validation.doc.isv/overview.html')
| -rw-r--r-- | docs/org.eclipse.wst.validation.doc.isv/overview.html | 88 |
1 files changed, 0 insertions, 88 deletions
diff --git a/docs/org.eclipse.wst.validation.doc.isv/overview.html b/docs/org.eclipse.wst.validation.doc.isv/overview.html deleted file mode 100644 index e71ef7f6b..000000000 --- a/docs/org.eclipse.wst.validation.doc.isv/overview.html +++ /dev/null @@ -1,88 +0,0 @@ -<html> -<head> -<title>Validation Framework Overview</title> -</head> -<body> -<p>A framework for calling validators that are build based.</p> -<h2>Approach</h2> -<p>In WTP 3.0 a new validation framework has been added. This was developed at -the request of validator owners and end users. To ease the transition to this -new framework, that approach that has been taken is to support both the old and -the new frameworks for a while. This means that the old validators work exactly -like they used to. They can still plug into the old framework and will continue -to be run by the old framework. This allows validator owners to migrate at their -own pace.</p> -<p>For validator owners that wish to exploit the new framework, it has been -designed n such a way to minimize the transition from the old framework to the -new framework. There is a new extension point that needs to be specified, and a -new abstract class that needs to be extended.</p> -<h3>Benefits</h3> -<p>What benefits does the new framework have to offer? Or asked another way, as -a validator owner, why would I want to switch?</p> -<h4>Performance</h4> -<h5>Tuning</h5> -<p>The main reason for creating a new framework was to improve performance. As -more and more validators are added, validation is consuming a bigger slice of -the resources that it takes to perform a build.</p> -<p>The best performance improvement is eliminating unnecessary work. We -eliminate work, by providing significantly more tuning options. Validation -owners can tune which resources they are called on. This is done through the use -of filter rules. These filter rules are grouped into inclusion and exclusion -groups. If you have multiple inclusion groups they are "anded" together, meaning -that each of the inclusion groups must have at least one successful filter rule. -Exclusion groups are used to specify what doesn't get validated. Exclusion -groups have a higher precedence than inclusion groups. If an exclusion group -excludes a resource than it is excluded no matter what the inclusion groups may -say.</p> -<p>They are several different types of filter rules:</p> -<ul> - <li><strong>File extension</strong> - Rules based on the file extension. For - example, include all the files with extension *.xml.</li> - <li><strong>Folder or File name</strong> - Rules based on the folder or file - name. For example exclude all the resources in the build folder. File names - can be fully qualified, project relative names, e.g. <strong>WebContent/WEB-INF/web.xml</strong>, - or simple names, <strong>web.xml</strong>.</li> - <li><strong>Project nature</strong> - Projects with certain natures can be - either included or excluded.</li> - <li><strong>Facet</strong> - Projects with certain facets can be either - included or excluded.</li> - <li><strong>Content Type </strong>- Resources of a particular content type - can be included or excluded.</li> -</ul> -<p>The filter rules and groups form the building blocks of what gets validated. -</p> -<p>In terms of tuning however, the end user has the final say. The validator -owners specify the default filter rules and groups for their validator, but the -end user through the use of preferences can override these settings. </p> -<h5>Caching</h5> -<p>Another way that performance is improved is through more effective caching. -With the previous framework we were noticing that different validators would be -opening and processing the same file, but that this would happen far enough -apart, that caches weren't effective. Even if files were being cached, the -second (or third, or forth, ...) open would happen far enough a means that way -that the file would have already been evicted from the cache. In the new -framework, the processing order is more tightly controlled. The framework calls -the validator and tells it what to validate. This way files are processed in -order, which means that the chance of them being a cache is much higher. Every -validator that is interested in file A processes it, and then we move on and -every validator that is interested in file B processes it, etc.</p> -<p>Also because state information is kept for the lifetime of the validation -operation, validators can cache expensive operations, like model creation, that -might be needed as part of validating several files. </p> -<h5>Job Control</h5> -<p>With the earlier framework, there were too many jobs/threads running -concurrently. This is now more tightly controlled.</p> -<h4>Dependency Support</h4> -<p>Another new feature is dependency support. A validator can now assert that a -resource is dependant on some other resources. For example that a XML file is -dependant on a XSD file. Now if the XSD file changes the XML can be revalidated. -As the user comes to trust this dependency support, they wont perform as many -clean builds.</p> -<h4>Primary Framework</h4> -<p>This is the primary validation framework. At some point, the earlier -framework will be deprecated and then removed. All the new investment will -happen in this framework. </p> -<p>The framework collateral will continue to be enhanced (junit testcases, -documentation, performance improvements, ...)</p> -</body> -</html>
\ No newline at end of file |