wst/components/validation/ValidationFrameworkRework.xml - gerrit/www.eclipse.org/webtools - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <?xml-stylesheet type="text/xsl" href="../../../wtp.xsl"?>
 <html>
 	<head>
 		<meta name="root" content="../../../../" />
 		<title>overview</title>
 	</head>

    <body>
       <h1>Validation Framework Enhancements</h1>

 	  <h2>Introduction</h2>
       <p>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</p>
 	  <br/>
       <h2>UI Changes</h2>

 	  <h4>Global Preferences Page</h4>
       <p> This prefernce page can be launcheg through Window -> Preferences -> Validation. A screen cap of the changed page is shown below</p>
 	  <br/>
 	  <img border="0" src="images/GlobalPreferencesReworkedImages.jpg"/>
 	  <br/>
 	  <p>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 <b>Disable all validation restoring user preferences</b> is global control to turn off all validation accros the workbench without losing the preferences the user has already selected. The <b>Enable All</b> and <b>Disable All</b> buttons are for enabling and disabling all manual and build validation.</p>
 	  <br/>
       <h4>Project Properties Page</h4>
       <p> 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</p>
  	   <br/>
  	  <img border="0" src="images/ValidationPropertiesReworkedImages.jpg"/>
 	  <br/>
 	  <p>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 <b>Disable all validation restoring user preferences</b> is a global control to turn off all validation accros the workbench without losing the preferences the user has already selected. The <b>Enable All</b> and <b>Disable All</b> buttons are for enabling and disabling all manual and build validation. The <b>Global Preferences...</b> hot link in the upper right hand corner is convienience to launch the global preferences page and change the global settings</p>
 	  <br/>
 	  <h2>Non UI Changes and Enhancments</h2>
 	  <br/>
 	   <h3>Ability to  run Validators as background jobs</h3>

 	   <ol>

 	   <li>
 		 <p>
 			A <b>new interface</b> is added to the framework, and will
 			need to be implemented by the clients to run the validator as a Job.

 			<br/>


 			<br/>
 			<br/>
 				<pre>
 public interface IValidatorJob extends IValidator {

  public IStatus validateInJob(IValidationContext helper, IReporter reporter) throws ValidationException;
  public ISchedulingRule getSchedulingRule(IValidationContext helper);

 }
 				</pre>
 		 </p>

 		 Also Client
 		 <ul>
 		  <li>
 		 Should return status of execution as IStatus to the framework.
 		 </li>
 		 <br/>
 		 <br/>
 		 <li>
 		 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.

 		 </li>
 		  <br/>
 		  <br/>
 		 <li>
 		 Need to poll the isCancelled() method of IReporter.
 		 </li>
 		  <br/>
 		  <br/>
 	 	<li>
 		Publish task information to the progress monitor using displaySubtask() of IReporter.
 	 	</li>
 		 </ul>

 		 </li>
 		 <br/>
 		 <br/>
 		 <li>
 		 <p>
 		 To maintain <b>backward compatibility</b> in the framework, IValidatorJob  has been extended from
 		 IValidator and  hence will require clients to implement:

 <pre>
 public void validate(IValidationContext helper, IReporter reporter) throws ValidationException;
 </pre>

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

 	<li><b>Job Family </b> <br/>
 	   Each and every validator is part of the jobFamily with the name: &lt;Project Name&gt;+ ValidatorManager.VALIDATOR_JOB_FAMILY
 	</li>

 	</ol>
       <br/>
       <h3>Facets Support</h3>
       <p>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 <b>facet</b> is added to the <b>validator</b> extension point as shown below.</p>

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

 	   <h3>Multiple markers per Validator support</h3>
       <p>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.</p>

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

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

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

     <p>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.</p>
     <li>If no custom marker is defined by the validator extension, the core validation marker is used</li>
     <li>If one custom maker is defined then that marker will be used</li>
     <li>If more than one marker is defined then each validation message that is added as a problem marker needs to set the marker id on the Message object that is created. If no marker id are set on the message objects then the default base validation marker will be used.</li>


    </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<?xml-stylesheet type="text/xsl" href="../../../wtp.xsl"?>
	<html>
	<head>
	<meta name="root" content="../../../../" />
	<title>overview</title>
	</head>

	<body>
	<h1>Validation Framework Enhancements</h1>

	<h2>Introduction</h2>
	<p>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</p>
	<br/>
	<h2>UI Changes</h2>

	<h4>Global Preferences Page</h4>
	<p> This prefernce page can be launcheg through Window -> Preferences -> Validation. A screen cap of the changed page is shown below</p>
	<br/>
	<img border="0" src="images/GlobalPreferencesReworkedImages.jpg"/>
	<br/>
	<p>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 <b>Disable all validation restoring user preferences</b> is global control to turn off all validation accros the workbench without losing the preferences the user has already selected. The <b>Enable All</b> and <b>Disable All</b> buttons are for enabling and disabling all manual and build validation.</p>
	<br/>
	<h4>Project Properties Page</h4>
	<p> 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</p>
	<br/>
	<img border="0" src="images/ValidationPropertiesReworkedImages.jpg"/>
	<br/>
	<p>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 <b>Disable all validation restoring user preferences</b> is a global control to turn off all validation accros the workbench without losing the preferences the user has already selected. The <b>Enable All</b> and <b>Disable All</b> buttons are for enabling and disabling all manual and build validation. The <b>Global Preferences...</b> hot link in the upper right hand corner is convienience to launch the global preferences page and change the global settings</p>
	<br/>
	<h2>Non UI Changes and Enhancments</h2>
	<br/>
	<h3>Ability to run Validators as background jobs</h3>

	<ol>

	<li>
	<p>
	A <b>new interface</b> is added to the framework, and will
	need to be implemented by the clients to run the validator as a Job.

	<br/>


	<br/>
	<br/>
	<pre>
	public interface IValidatorJob extends IValidator {

	public IStatus validateInJob(IValidationContext helper, IReporter reporter) throws ValidationException;
	public ISchedulingRule getSchedulingRule(IValidationContext helper);

	}
	</pre>
	</p>

	Also Client
	<ul>
	<li>
	Should return status of execution as IStatus to the framework.
	</li>
	<br/>
	<br/>
	<li>
	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.

	</li>
	<br/>
	<br/>
	<li>
	Need to poll the isCancelled() method of IReporter.
	</li>
	<br/>
	<br/>
	<li>
	Publish task information to the progress monitor using displaySubtask() of IReporter.
	</li>
	</ul>

	</li>
	<br/>
	<br/>
	<li>
	<p>
	To maintain <b>backward compatibility</b> in the framework, IValidatorJob has been extended from
	IValidator and hence will require clients to implement:

	<pre>
	public void validate(IValidationContext helper, IReporter reporter) throws ValidationException;
	</pre>

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

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

	</ol>
	<br/>
	<h3>Facets Support</h3>
	<p>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 <b>facet</b> is added to the <b>validator</b> extension point as shown below.</p>

	<pre>
	<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>
	</pre>

	<h3>Multiple markers per Validator support</h3>
	<p>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.</p>

	<pre>
	<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>
	</pre>

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

	<pre>
	<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>
	</pre>

	<p>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.</p>
	<li>If no custom marker is defined by the validator extension, the core validation marker is used</li>
	<li>If one custom maker is defined then that marker will be used</li>
	<li>If more than one marker is defined then each validation message that is added as a problem marker needs to set the marker id on the Message object that is created. If no marker id are set on the message objects then the default base validation marker will be used.</li>


	</body>
	</html>