Home » Eclipse Projects » Eclipse Platform » Programmatic handler enablement
| | | | |
Re: Programmatic handler enablement [message #540095 is a reply to message #540089] |
Mon, 14 June 2010 21:07 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Paul Webster wrote on Mon, 14 June 2010 16:24 |
Outside of that, you would have to decide when to update your handler
enabled state. 2 options come to mind. Either your handler becomes a
listener for an appropriate event in your model and you update your
state then, or at some change that's important to your handler you call
handler.setEnabled(evaluationService.getCurrentState()) if using
setEnabled(*)
|
Ah good, we're on the same wavelength now. I do lot's of programmatic handling for various events but I should also have been clear that here I'm wanting to update based on selections in the platform views that I don't have access to, i.e. package explorer, navigator. So I need to listen to generic file selection events, basically. I realize that there is a tradeoff here for these system views because you run the danger of a lot of consumers writing complex enablement checks every time a user changes the file selection, but I'm wondering if there is a programmatic hook here.
To out things in a little more context, it might be possible that what I want to do is definable declaratively, but I need to get things like containing project builder ID that I'm very comfortable working with programmatically but I just can't figure out how to accomplish in the xml def. And I may also have things that I just need to do programmatically. So sorry if this is an obvious question, but is there a way to simply call a method on an arbitrary (adapted?) class and have the selected items passed in to it? I hope that question makes sense..
cheers,
Miles
|
|
| |
Re: Programmatic handler enablement [message #540335 is a reply to message #540215] |
Tue, 15 June 2010 17:32 |
Miles Parker Messages: 1341 Registered: July 2009 |
Senior Member |
|
|
Paul Webster wrote on Tue, 15 June 2010 08:16 |
In the declarative XML there are property testers.
<with variable="selection">
<iterate ifEmpty="false">
<adapt type="org.eclipse.core.resources.IResource">
<test property="org.eclipse.core.resources.name"
value="*.java"/>
</adapt>
</iterate>
</with>
You can use <test/> to call a property tester [1], and the EP
org.eclipse.core.expressions.propertyTesters to define your own. We
ship with some pre-defined ones for dealing with resources [2],
including getting a projects properties and projectNature.
|
OK, I got up to the example point, but where I get really stuck with the declarative stuff is when trying to work with more complex relationships. So for example, the above gives me the files with .java, but given such an adapted file, how do I then get it's enclosing project and test the properties on that? Or perhaps I do need my own property tester for this case, which would allow me to write all of that logic in Java which would probably be more maintainable. Anyway the property testers look like what I want -- I hadn't realized how open ended they were -- sort of like "EnablementProviders" really..
Quote: | The caveat ... try not to put a property tester in your UI plugin, since
once the tester has been loaded the framework is free to load and
instantiate anything it feels like.
|
Hmm...do you mean then that if I have a foo.ui <- foo.core then I should keep the testers and so on in a small standalone plugin like foo.ui <- *foo.resources* <- foo.core to avoid loading my other UI stuff if the users aren't actually going to be working with the adapted types?
|
|
|
Re: Programmatic handler enablement [message #540503 is a reply to message #540335] |
Wed, 16 June 2010 12:22 |
|
Miles Parker wrote:
> Paul Webster wrote on Tue, 15 June 2010 08:16
>> In the declarative XML there are property testers.
>> <with variable="selection">
>> <iterate ifEmpty="false">
>> <adapt type="org.eclipse.core.resources.IResource">
>> <test property="org.eclipse.core.resources.name"
>> value="*.java"/>
>> </adapt>
>> </iterate>
>> </with>
>>
>> You can use <test/> to call a property tester [1], and the EP
>> org.eclipse.core.expressions.propertyTesters to define your own. We
>> ship with some pre-defined ones for dealing with resources [2],
>> including getting a projects properties and projectNature.
>
>
> OK, I got up to the example point, but where I get really stuck with the
> declarative stuff is when trying to work with more complex
> relationships. So for example, the above gives me the files with .java,
> but given such an adapted file, how do I then get it's enclosing project
> and test the properties on that?
My examples was just an example of using the property testers, not
relevant to your situation. But it depends. The core resource property
tester has a couple of project properties. projectNature,
projectPersistentProperty, and projectSessionProperty are applied
against the project of the selected resource (the PT simply goes
resource.getProject()). So if you select a java file, you can still
check its project nature.
> Or perhaps I do need my own property
> tester for this case, which would allow me to write all of that logic in
> Java which would probably be more maintainable. Anyway the property
> testers look like what I want -- I hadn't realized how open ended they
> were -- sort of like "EnablementProviders" really..
Once you write your property tester, there are some minor best
practices, but they're basically an "escape to assembler". You get a
test(*) method, return true or false :-)
> Hmm...do you mean then that if I have a foo.ui <- foo.core then I should
> keep the testers and so on in a small standalone plugin like foo.ui <-
> *foo.resources* <- foo.core to avoid loading my other UI stuff if the
> users aren't actually going to be working with the adapted types?
It's just a reminder. If you have a property tester in a plugin and
that plugin is not activated, the PT will evaluate to TRUE (technically
returns NOT_LOADED) for most of the workbench. Once the containing
bundle is active, then the PT gets to return TRUE/FALSE.
For RCP apps where they want accuracy, <test/> comes with a
forcePluginActivation attribute, to allow the core expression to load
the PT if it is not active.
Then the fallout is: If you force a PT to load, you activate that
plugin. If it contains UI elements like actionSets/popupMenus,
org.eclipse.ui.menus, commands/handlers (anything that supports delayed
loading) the framework is now free to load that contributions.
It's the standard warning that Eclipse plugins should delay loading
until a user action requests their functionality (click on a menu item
or tool item, execute a keybinding, show a view, etc).
Sometimes it's unavoidable, but you'll have to decide if putting the PT
in your core (which I'm guessing doesn't deal with resources) is worth
splitting it out from your UI plugin (which may only have a few
contributions).
Later,
PW
--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse .platform.doc.isv/guide/workbench.htm
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 17:24:34 GMT 2024
Powered by FUDForum. Page generated in 0.04688 seconds
|