The Validation Framework in validation component of wst sub project has been reworked to improve the overall performance of client validators that are built using the framework. The rework will be available in WTP 1.5 release. The rework had been in both UI and Non UI areas. The UI changes are mainly to simplify useability and give more granular control of when client validators are run at project level and global level. The non UI changes is mainly the addition of Job support into the framework. Addtionaly there are also some Feature Enahancemenets done. All the UI and Non UI and Enhancement changes and how they effect the implementation of client validators are explained in detail below

Global Preferences Page

This prefernce page can be launcheg through Window -> Preferences -> Validation. A screen cap of the changed page is shown below

The table contains all the validators in the workbench that extend the framework. Each validator now has extra controls for Manual and Build validation. The Manual (Tiggered by user using "Run Validation" menu action) and Build (Triggere through incremental or auto build) columns in the table represent how validation is kicked off. This way the user has a choice to turn any expensive validators on Manual or Build validation. Each validator can have the values set independently. The Disable all validation restoring user preferences is global control to turn off all validation accros the workbench without losing the preferences the user has already selected. The Enable All and Disable All buttons are for enabling and disabling all manual and build validation.

Project Properties Page

This properties page can be launched by right click of a Project -> Select Properties -> Validation. A screen cap of the changed page is shown below

The properties page table contains all the validators that are valid for the selected project that extend the framework. Similar to the global preferences page each validator now has extra controls for Manual and Build validation. The Manual (Triggered by user using "Run Validation" menu action) and Build (Triggered through incremental or auto build) columns in the table represent how validation is kicked off. This way the user has a choice to turn any expensive validators on Manual or Build validation on per project basis. Each validator can have the values set independently. The Disable all validation restoring user preferences is a global control to turn off all validation accros the workbench without losing the preferences the user has already selected. The Enable All and Disable All buttons are for enabling and disabling all manual and build validation. The Global Preferences... hot link in the upper right hand corner is convienience to launch the global preferences page and change the global settings

1. A new interface is added to the framework, and will need to be implemented by the clients to run the validator as a Job.
   
   
   

   public interface IValidatorJob extends IValidator {
    
    public IStatus validateInJob(IValidationContext helper, IReporter reporter) throws ValidationException;
    public ISchedulingRule getSchedulingRule(IValidationContext helper);
    
   }				
   				

   Also Client
   • Should return status of execution as IStatus to the framework.
   
   
   
   • May provide scheduling rule to the framework through getSchedulingRule(). The default scheduling rule used by the framework is empty scheduling rule. Returning null from the getSchedulingRule() will make the framework to use the default.
   
   
   
   • Need to poll the isCancelled() method of IReporter.
   
   
   
   • Publish task information to the progress monitor using displaySubtask() of IReporter.




2. To maintain backward compatibility in the framework, IValidatorJob has been extended from IValidator and hence will require clients to implement:

   public void validate(IValidationContext helper, IReporter reporter) throws ValidationException;
   

   but this method will never be invoked by the framework once you implement validateInJob, hence an empty implementation will be enough.

3. Job Family
   Each and every validator is part of the jobFamily with the name: <Project Name>+ ValidatorManager.VALIDATOR_JOB_FAMILY

In the past validators could only be filtered on project natures, with the introduction of facets in WTP, the filtering mechanism has been expanded to filters on facets in addtion to natures. With the current implementation the validators are can be filtered on Facets, Project Natures or both. A new element called facet is added to the validator extension point as shown below.

	
		<extension
	         id="EJBValidator"
	         name="%EJB_VALIDATOR"
	         point="org.eclipse.wst.validation.validator">
	      	<validator>
	      		<facet
               	  		facetId="jst.ejb">
         		</facet>
		         <projectNature
		               id="org.eclipse.wst.common.modulecore.ModuleCoreNature">
		         </projectNature>
		         <filter
		               objectClass="org.eclipse.core.resources.IFile"
		               nameFilter="ejb-jar.xml">
		         </filter>
		         <filter
		               objectClass="org.eclipse.core.resources.IFile"
		               nameFilter="*.class">
		         </filter>
		         <filter
		               objectClass="org.eclipse.core.resources.IFile"
		               nameFilter="*.java">
		         </filtergt;
		         <helper
		               class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.EJBHelper">
		         </helper>
		         <dependentValidator
		               depValValue="true">
		         </dependentValidator>
		         <markerId
		               markerIdValue="EJBValidatorMarker">
		         </markerId>
		         <run
		               class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.UIEjbValidator">
		         </run>
	      	</validator>
	   </extension>
	  

There has been a need expressed by adopters of the validation framework to support multiple marker support for validators. This support would help these validators in taking advantage of the org.eclipse.ui.ide.markerResolution extension point where they can provide resolution (Quick Fix) for each problem marker type. The multiple marker support it now enabled. Each validator can define more than one marker using marker id elements as shown below.

	
		<extension
	         id="EJBValidator"
	         name="%EJB_VALIDATOR"
	         point="org.eclipse.wst.validation.validator">
	      	<validator>
	      		<facet
               	  		facetId="jst.ejb">
         		</facet>
		         <projectNature
		               id="org.eclipse.wst.common.modulecore.ModuleCoreNature">
		         </projectNature>
		         <filter
		               objectClass="org.eclipse.core.resources.IFile"
		               nameFilter="ejb-jar.xml">
		         </filter>
		         <filter
		               objectClass="org.eclipse.core.resources.IFile"
		               nameFilter="*.class">
		         </filter>
		         <filter
		               objectClass="org.eclipse.core.resources.IFile"
		               nameFilter="*.java">
		         </filtergt;
		         <helper
		               class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.EJBHelper">
		         </helper>
		         <dependentValidator
		               depValValue="true">
		         </dependentValidator>
		         <markerId
		               markerIdValue="EJBValidatorMarker">
		         </markerId>
		         <markerId
		               markerIdValue="EJBValidatorMarker1">
		         </markerId>
		         <run
		               class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.UIEjbValidator">
		         </run>
	      	</validator>
	   </extension>
	  

Each additional marker defined in the validator extension needs a corresponding marker defined extending the org.eclipse.core.resources.markers extension point as shown below.

      <extension
         id="EJBValidatorMarker1"
         name="%EJB_VALIDATION_PROBLEMMARKER_NAME_1"
         point="org.eclipse.core.resources.markers">
      <super
            type="org.eclipse.wst.validation.problemmarker">
      </super>
      <persistent
            value="true">
      </persistent>
      <attribute
            name="owner">
      </attribute>
      <attribute
            name="validationSeverity">
      </attribute>
      <attribute
            name="targetObject">
      </attribute">
      <attribute
            name="groupName">
      </attribute">
      <attribute
            name="messageId">
      </attribute>
    </extension>
    

Here are the rules that the framework follows to decide which validation marker should be used to add a problem marker to the problems view.