| Handler expression evaluation time [message #489618] |
Mon, 05 October 2009 11:07  |
 Stewart Francis
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
Hi,
I'm providing my own handler for the delete action, which supplies an
activeWhen element and an enabledWhen element as follows:
<handler commandId="org.eclipse.ui.edit.delete"
class="foo.DeleteHandler">
<activeWhen>
<with variable="activeMenuSelection">
<iterate ifEmpty="false" operator="and">
<instanceof value="foo.A" />
</iterate>
</with>
</activeWhen>
<enabledWhen>
<with variable="activeMenuSelection">
<iterate ifEmpty="false" operator="and">
<property="foo.properties.checkPermission" value="Delete" />
</iterate>
</with>
</enabledWhen>
</handler>
And the following property tester declaration:
<extension point="org.eclipse.core.expressions.propertyTesters">
<propertyTester id="foo.PropertyTester"
type="foo.SuperOfA"
namespace="foo.properties"
properties="checkPermission"
class="foo.PropertyTester">
</propertyTester>
</extension>
This works as intended: to activate my handler when an the
activeMenuSelection is comprised entirely of instances of A, and enable
it when the property evaluates to true. However, I find that my
property tester is invoked by evaluation of the check enablement
expression whenever the active menu selection changes (restricted by the
active selection being an instance of foo.SuperOfA), regardless of the
activation of the handler. This seems unnecessary to me - I'd assumed
that the enablement was a property of the handler, which in the event
that the handler is inactive, is irrelevant. Is this an incorrect
assumption?
Is this not also a potential performance issue? The property tester in
question acts as an interface for the core expressions framework into a
generic checkPermissions method in my RCP, used to determine permissions
for all actions/commands. If I were to expand my use of this property
tester, would it not be invoked for all commands in my RCP which
reference it in an enabledWhen clause (assuming all of my command
handlers are registered for some subtype of foo.SuperOfA)? i.e. at the
moment, the property tester is invoked to check permissions for Delete
whenever the activeMenuSelection changes to any foo.SuperOfA, regardless
that it is only appropriate to check permissions for delete if the
activeMenuSelection is a foo.A.
Also, the checkPermissions operation could be time consuming. I'm
currently using the work-around of repeating my handler's activeWhen
expression in the enabledWhen clause, to prevent invocation of the
checkPermissions method when not appropriate.
Is there some better way of doing this?
This is using eclipse 3.4.2
Hope this makes sense! Any advice greatly appreciated.
Stewart Francis
|
|
|
| Re: Handler expression evaluation time [message #489642 is a reply to message #489618] |
Mon, 05 October 2009 13:04  |
|
Your probably in as good a shape as it gets.
The good pattern in your case would be:
<enabledWhen>
<with variable="activeMenuSelection">
<iterate ifEmpty="false" operator="and">
<instanceof value="foo.A" />
<property="foo.properties.checkPermission" value="Delete" />
</iterate>
</with>
</enabledWhen>
Explanation of behaviour:
Expressions are evaluated based on changes to the variables they use. i.e. you use "activeMenuSelection" and so every time that value changes, all expression referencing it are re-evaluated. (requesting a re-evaluation of your property will also cause all expressions using it to re-evaluate).
But you can't register an expression X and say "only evaluate if expression Y evaluates to true" ... the expression engine does have optimizations in it, but not that one (that's an optimization of the client use of expressions, not the expression engine).
As it turns out your expression is evaluated on every activeMenuSelection change, and when the selection doesn't contain a SuperOfA it throws a CoreException "no property tester contributes 'foo.properties.checkPermission' to type 'whatever'". This is by design, but it turns out you can optimize your expressions by adding the instanceof check before the "test".
PW
|
|
|
|
Powered by
FUDForum. Page generated in 0.02713 seconds
Search
Help
Register
Login
Home
