| <?xml version="1.0" encoding="utf-8"?> | |
| <!--Arbortext, Inc., 1988-2006, v.4002--> | |
| <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN" | |
| "reference.dtd"> | |
| <reference id="rtunevalidat" xml:lang="en-us"> | |
| <title>Tuning validators</title> | |
| <shortdesc>Whether or not a validator validates a particular resource depends | |
| on the filters that are in place for that validator.</shortdesc> | |
| <prolog><metadata> | |
| <keywords><indexterm>code validation<indexterm>tuning</indexterm></indexterm> | |
| <indexterm>validation<indexterm>tuning</indexterm></indexterm></keywords> | |
| </metadata></prolog> | |
| <refbody> | |
| <section><p>When a validator is first developed, the implementer of the validator | |
| defines a default set of filters. These filters may be based on:<ul> | |
| <li>file extensions</li> | |
| <li>folder of file names</li> | |
| <li>project natures</li> | |
| <li>project facets</li> | |
| <li>content types</li> | |
| </ul>Through the Validation Filters dialog, you are able to further tune these | |
| settings.Normally you would simply keep the defaults, however two reasons | |
| why you may want to tune validation are:<ul> | |
| <li>Performance: if you have a very large workspace, you could reduce the | |
| amount of validation.</li> | |
| <li>Non standard conventions: if you use a non standard naming convention | |
| (for example stores XML in files with an .acme-xml extension), you could still | |
| enable the appropriate validators to run against those files.</li> | |
| </ul>You can access this dialog by clicking <menucascade><uicontrol>Window</uicontrol> | |
| <uicontrol>Preferences</uicontrol><uicontrol>Validation</uicontrol></menucascade> and | |
| then clicking <uicontrol>Settings</uicontrol> beside each validator.</p><p>Filters | |
| are stored in groups. There are two types of groups: Include groups and Exclude | |
| groups. You can have as many Include groups as you like. Filters inside of | |
| an Include group cause resources to be validated. If any rule matches then | |
| the entire group matches. Inside of a group the filter rules are OR’d together. | |
| However individual Include groups are AND’ed together. You can have one Exclude | |
| group. If any of its filter rules match, then the resource is excluded. Exclusion | |
| takes precedence over inclusion.</p></section> | |
| <example><p>These rules are illustrated with this hypothetical example:<image | |
| href="../images/validatefilters.jpg" placement="break"><alt>screen capture | |
| of the validation filters panel showing include and exclude groups</alt></image><ul> | |
| <li>If the resource is in the disabled folder, it will be excluded because | |
| exclusion takes precedence over everything else.</li> | |
| <li>If the resource does not have the JSP source content type, and it does | |
| not have the JSP fragment source content type, and it does not have a file | |
| extension of .jsp or .jspf then it will be excluded because none of the rules | |
| in the first group matched.</li> | |
| <li>If the project does not have the module core nature then it will be excluded | |
| because the single rule in the second group did not match.</li> | |
| <li>Otherwise the resource will be validated by this particular validator.</li> | |
| </ul>To add a rule to a group, select the group on the left, and click <uicontrol>Add | |
| Rule</uicontrol>.</p></example> | |
| </refbody> | |
| </reference> |