Description Peter Moogk 2007-11-15 17:29:40 EST

Eclipse has done a great job for providing enablement filtering that can be defined in plugin.xml meta data.  Eclipse has defined a global element called enablement to encourage developers to include this element in their own extension points.  So far this is all great.  However, if an extension point developer wants to connect the enablement elements that they define into the Eclipse enablement framework they currently need to define a property tester. 
This property tester does the work of pulling together the enablement elements that it defines, evaluating each one, and finally returning a composite result. 

This approach works, but it has the drawback that the property tester code must be loaded via a plugin.  The Eclipse enablement framework does not always load
property tester code, which can cause problems.  For example if the developer uses their property tester in the context of a property page enableWhen filter and the property tester code has not been loaded the framework will leave the property tester unloaded and assume a true condition.  This will result in the property page coming up for projects that it was not intended for.  In the context of a property page,  property tester code is never loaded even if the property tester sets the forcePluginActivation attribute to true.  If the extension point developer feels strongly that the property page should not be displayed they will be forced to ensure that their property tester code is always loaded by hooking the Startup extension point, which isn't a great thing to do performance wise.

Given the problem described above of using a property tester to connect a global enablement element to the framework, it would be nice if there was a way to do this connection via meta data instead of via a property tester.  This would avoid completely the problems that the property tester introduces.

I have included below a possible solution to this problem.  I have also attached a proposed patch that implements the proposal described below.   
The proposal is fairly simple.  The extension point developer needs a way to specify in meta data the extension point that contains the enablement element as well the XML path that should be used to locate the enable element in the extension point.  

If an extension point developer created an extension point called some.extension.namespace.pointid and defined an enablement element under the rootElement/subElement branches of the XML tree.  It might looks something like this:

   <extension point="some.extension.namespace.pointid">
     <rootElement>
         <someOtherElement/>
         <subElement>
             <enablement>
                <test property="org.eclipse.core.resources.projectNature"
                      value="org.eclipse.jdt.core.javanature" />
            </enablement>
        </subElement>
    </rootElement>


If the developer wanted to connect this global enablement element into the Eclipse filtering framework they would define an expression defintion something like this:

   <extension  point="org.eclipse.core.expressions.definitions">
        <definition id="some.extension.namespace.pointid.def">
           <iterateExtensions
               extensionPointId="some.extension.namespace.pointid"
               pathToEnablement="rootElement/subElement/enablement"
               operator="or"
               allowPluginLoad="true"/>
         </definition>
   </extension>

In the example above the developer would use a proposed new iterateExtensions filtering element to indicate where they defined their enablement element.  The 
pathToEnablement attribute specifies where in the extension xml tree the enablement element can be found.  The operator attribute can be either "and" or "or" in the same way that the current iterate element has these values.  The allowPluginLoad attribute specifies whether the context of these global enablement elements should load property testers or not.  Note: this allowing of the loading of property tester is restricted to the enablement elements defined by the extenders of the some.extension.namespace.pointid extension point.   Note2: if the operator attribute is not specified it would be defaulted to "or".  If the allowPluginLoad attribute is not specified it would be defaulted to false.

This new iterateExtensions filtering element could be made available in all contexts where filtering elements are used, however, I would recommend that it only be used in the context of definitions extension points.  Since, there is some overhead to convert all the global enablement elements into Expression objects this conversion work would be done over and over again if the iterateExtensions element were allowed to be located in all filtering element locations.  However, all definition Expression objects are cached so this work would only be done once.  It would definitely be more convienent to have the iterateExtensions usable everywhere, but I think it is a reasonable tradeoff to have it only specifiable in a definitions extension.

To finish this example, I have included a property page extension below that uses the some.extension.namespace.pointid.def definition defined above.  In this example the adapted IProject object would be passed as the default variable for the context of each of the global enablement elements.  Since the "or" operator was specified in the iterateExpressions element any global element which returned TRUE or NOT_LOADED would cause the property page to be displayed.

   <extension point="org.eclipse.ui.propertyPages">
      <page
            name="page name"
            class="org.example.PropertyPageClass"
            id="some.extension.namespace.pageid">
           
            <enabledWhen>
               <adapt type="org.eclipse.core.resources.IProject"> 
                   <reference   
                      definitionId="some.extension.namespace.pointid.def" />
               </adapt> 
            </enabledWhen>
      </page>
   </extension>