|
| Re: Performance: logic in SourceProvider or activeWhen? [message #554172 is a reply to message #554164] |
Fri, 20 August 2010 12:21  |
 Daniel Krügler
Messages: 853
Registered: July 2009 |
Senior Member |
|
|
On 20.08.2010 13:39, Rainer wrote:
> Hello,
>
> in my plugin, I enable and disable commands by using SourceProviders.
>
> Currently, the logic that decides about the enabling is located in the
> SourceProvider which then simply provides a String that is evaluated via
> <equals> in the <activeWhen> of the handler.
>
> The more usual way seems to be providing a "real" part of my domain
> model via the SourceProvider which is then evaluated in the <activeWhen>
> using Eclipse expressions. But if that evaluation is rather complex
> (e.g. involving possibly large collections), I can imagine that this
> usual way is inferior performance-wise because I think that the
> activeWhen is way more often checked/called than my SourceProvider,
> which is only called manually by me.
>
> My question is now simply if this assumption is true
This can not be answered in general. The right way to get an answer
for this question is to test, whether it makes a noticable difference
on *your* scenario.
> and I should
> therefore keep my evaluation logic in the SourceProvider (as Java code)
> and not move it to the plugin.xml (XML Eclipse expressions). An
> additional benefit would be that there only is one place where "real"
> evaluation (in the sense of doing more than just checking Strings) is
> done, namely the SourceProviders, rather than splitting that logic into
> a Java and an XML part.
>
> I really want to comply with the standards but sacrificing performance
> would just not be worth it for me...
There does not exist such a standard. Nevertheless, it is often useful
to separate concerns to reduce dependencies among actually unrelated
components. If the xml-expression evaluation is too slow you might
want to consider the combination of a PropertyTester defined by the
extension point org.eclipse.core.expressions.propertyTesters and
indirectly referred to by the "test" element within visibleWhen
or enabledWhen elements. The indirect reference happens via the
combination of property and args. The "property" shall denote
a valid concatenation of the namespace and one of the properties
listed in org.eclipse.core.expressions.propertyTesters. The "args"
property is a domain-specific way to extend the functionality of
a given PropertyTester. It is only provided to the PropertyTester
itself and thus depends on the meaning, the individual property
tester is defining for it. Thus, this is an API contract of a given
property tester. The advantage of this key-based approach is, that
a given property tester can easily extend it's set of know
arguments.
HTH & Greetings from Bremen,
Daniel Krügler
|
|
|
Powered by
FUDForum. Page generated in 0.02945 seconds
] 
Search
Help
Register
Login
Home
