Community
Participate
Working Groups
The org.eclipse.ui.decorators extension point 'enablement' element does not support the property tester 'test' sub element. The 'enablement' element does define a notion of 'objectState' element which appears to be similar to a property tester, however because the object state object must implement the org.eclipse.ui.IActionFilter this means the objectState enablement object must be defined in a UI plugin which is limiting. Our specific adopter scenario is we are decorating an org.eclipse.jdt.core.IMethod object. This method should only be considered for decoration if this project contains certain facets (org.eclipse.wst.common.facets). There are already property testers in place down in some of the lower level non UI plugins of WTP capable of making this determination, and these plugins are relatively lightweight to load (and the plugins are actually already loaded in our scenarios), so we would simply like to reuse those property testers. In any case, because we can not use those property testers our UI plugin is currently being loaded even if the user is not using any of our tooling as soon as the simplest Java file containing a method is opened. The only potential workaround I can see at this point is to use an objectState enablement element that is not defined in our plugin. Even if we did that though, it is still skirting the issue because whatever UI plugin the ojbecStateEnablement element is defined in will be forced to load.
Hey Jason, has any progress been made on this one?
No progress has been made as far as I can tell. I merely reported the bug.
Just a note: This would probably be solved by adding a new element, <enabledWhen/>, that provides access to core expressions like test. Allowing core expressions will turn any current <enablement/> elements into warning in the PDE editor. PW
Hi, Is there any outlook for triaging this? This is blocking some changes we are trying to make in the performance space, so we would like to get this one evaluated. Thanks.
Some thoughts: One issue with objectState is it depends on the first contributor to adapt an object to IActionFilter. Basically the first plugin to add "testable attributes" to an object type limits any other plugin from doing it. PW
Can this please be triaged? It is blocking some of our performance improvements.
Under the covers, DecoratorDefinition uses [older] ActionExpression. The property testers are not available in ActionExpression. To be able to use property testers we'll need to switch to using newer Expression class, meaning replacing the enablement evaluation for all existing decorators. Obviously that brings a great chance to create issues for existing decorators. Have you tried to place this into the 3.8 plan?
(In reply to comment #7) > To be able to use property testers we'll need to switch to using newer > Expression class, meaning replacing the enablement evaluation for all existing > decorators. Obviously that brings a great chance to create issues for existing > decorators. The newer core expressions can be added in a different element. If it's there, core expressions would be used (and any ActionExpression ignored), if not, the older ActionExpression would be used. Everything that currently works would continue to work, and users could opt in to the new expression if they want. PW
(In reply to comment #8) > The newer core expressions can be added in a different element. If it's there, > core expressions would be used (and any ActionExpression ignored), if not, the > older ActionExpression would be used. Yes, it could be done this way and it will solve this specific defect. On a larger picture, arguably, the biggest architecture problem in 3.x are multiple ways of doing the same thing that are "almost" the same. We already have 2 ways to specify decorator enablement, this will create a 3rd way. To me, this would be a gain for the specific problem vs. making overall picture more convoluted.
(In reply to comment #9) > Yes, it could be done this way and it will solve this specific defect. On a > larger picture, arguably, the biggest architecture problem in 3.x are multiple > ways of doing the same thing that are "almost" the same. We already have 2 ways > to specify decorator enablement, What are the 2 ways, ActionExpressions and something else? For going forward, core expressions and the IEvaluationService is the supported enablement story for 4.x. If something is to be done, it should be brought in line with that. PW
Any news on whether we should expect "a new way of doing this" in maybe, Juno? Or are we looking to work with the greater picture for 4.x? Just looking to see if we could get some sort of plan for this bug instead of losing track of it. Gary
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
