can anybody explain me how to dynamically enable/disable a command due to an application state? I've read Eclipse Help and all those wiki articles which has Paul Webster in its signature. But I still can't understand it.

There are property testers, contexts, command states, command parameters...can anybody give me a use case for all those terms??

On 05/02/2011 05:49 AM, Behnil wrote:
> Hi Prakash,
>
> it's very useful article you've done! It explained me lot of things
> about commands. But there are some questions I still have:
>
> How about the org.eclipse.ui.contexts? I suppose I can use it in
> activeWhen with variable "activeContexts" right? But what is useful for?

org.eclipse.ui.contexts are basically nothing more than IDs that can be
arranged hierarchically. Their meaning is up to the consumer. ex: the
keybinding system has a root id ...dialogAndWindows, with 2 children,
dialogs and windows (there's more as well). if windows is active, it
exposes one set of keybindings, if dialogs is active, it exposes
another, and both contexts imply dialogAndWindows is active (which
includes global keybindings). In theory, you would activate a context
if you want to activate a set of functionality, and de-activate it when
done, and if the functionality is outside the scope of your part lifecycle.

> Command's parameters. Can I contribute objects as parameters for
> commands? Or am I limited to use only Strings? If I can, how to do it,
> since declarative in menu contribution isn't that way I think.

You can use objects as command parameters (like IFile). That parameter
definition needs to include a type converter. Just an aside, command
parameters are not dynamic in nature (they're not like method parameters).

> What else except radio/toggle states are command's states for? I don't
> see the difference between states and parameters.

The state is a piece of information attached to that command, usually so
it is shared and can be used between the different handlers that may be
active. A text label to use, where current information is coming from,
the currently selected radio button, etc.

The short answer is they're for testing the properties of various
objects. They are a way to extend the core expression system. They're
like an "escape to assembler", as you are handed an object in your
test(*) method and get to return true or false :-)

If you are writing a core expression against a variable like
activePartId (String) you wouldn't really use a property tester. But if
you pick activeEditorInput, you usually adapt to IFile. At that point,
you need property testers to access the IFile's name, persistent
properties, parent project, extension, etc, as they're not exposed as
variables in the core expression system.

Thanks Paul, I think we are almost there But I'm really not sure about the propertyTesters.

> The short answer is they're for testing the properties of various
> objects. They are a way to extend the core expression system. They're
> like an "escape to assembler", as you are handed an object in your
> test(*) method and get to return true or false

So the object passed through to the propertyTester implementation is the one actually selected?
Let's have this example:

Now is the actually selected object adapted to IPerson and passed through to my property tester.
The tested property is "age" and expected value is "30". Right?

My last questions are:

1. If the selected file isn't adaptable to IPerson, the tester is not called at all, right?
2. Does the IPerson object need to contain the bean property "age"? Or the property name is only for my purpose?
3. When I use propertyTesters to test my own variables managed by an ISourceProvider, is that tester reevaluated automatically
always when the SourceProvider fires the change of its variable state?
4. Can be propertyTesters used to test properties of another objects except those derived from variables? (this question is maybe a complete drivel)

yes, although in the case of selection you would almost always have:
<iterate ifEmpty="false"><adapt ....></iterate>

> Now is the actually selected object adapted to IPerson and passed
> through to my property tester.

right.

> The tested property is "age" and expected value is "30". Right?

yes

> My last questions are:
>
> 1. If the selected file isn't adaptable to IPerson, the tester is not
> called at all, right?

if it fails to adapt, nothing within the adapt element is called.
Property testers can also be applied to a specific type. With adapt,
the type was already sorted out. When not using adapt an optimization
is to use the instanceof element as well. ex:
<iterate ifEmpty="false">
<instanceof value="org.example.IPerson"/>
<test property="test.something.age" .../>
</iterate>

> 2. Does the IPerson object need to contain the bean property "age"? Or
> the property name is only for my purpose?

No, it's just for the extension mapping. You could call it
test.something.testThatAge.

> 3. When I use propertyTesters to test my own variables managed by an
> ISourceProvider, is that tester reevaluated automatically always when
> the SourceProvider fires the change of its variable state?

The expression is re-evaluated when the variable changes, because source
providers fire events into the system. If the property itself changes,
there are no notifications and you need to use
org.eclipse.ui.services.IEvaluationService.requestEvaluation (String) to
tell the system that the property changed.

> 4. Can be propertyTesters used to test properties of another objects
> except those derived from variables? (this question is maybe a complete
> drivel)

yes ... maybe. Sorta :-) Once you're in the test(*) method, you can
call any API you can get your hands on, including
PlatformUI.getWorkbench(). Whether it's a good idea depends on your
specific usecase and what else is going on at the time.