eclipse TextActionHandle and the command framework

Eclipse has a TextActionHandler class (that uses the action framework) to handle global edit actions such as cut, copy and paste. This class has a hook for adding Text controls to it and when the text control is activated (because you have selected it or are editing it) it automatically translates the global edit actions to actions on the Text control. For application areas where you want the logical concept of the "delete" command to translate into something you want to do, for example, delete the currently selected domain object in a master list table viewer, you need to connect to the global command. The standard way has been to obtain the part site (editor or view) then use setGlobalActionHandler() to a locally defined action that then executes your logical "delete" command. Now, with the command framework, you can define a local IHandler object and using the IHandlerService obtained from the getEditorSite().getService(IHandlerService.class) method, you link your handler to the command (such as in the main toolbar) directly to your handler. Very nice. If you use the part site, the handler is even deactivitaed for you when your editor or view becomes deactivated, for example, when you change to another editor and focus leaves the current editor.

All very nice. However, there are many edit actions that constantly need this redirection and the repetition of using this mechanism (or being really clever and defining it in your plugin.xml file and then using property testers and activeWhen clauses) makes it a bit more challenging and some local handlers need complex logic in them. You could define an interface tag for your editor or view object and expose the edit actions at this level and define a handler that checks for this tag then invokes the action on the editor, or you can define a manager to manage multiple handlers in your editor or view and do something very local and programmatic.

I prefer the configured approach as much as possible of course but if your editor or view is composed of multiple composite objects or forms, such as in a master-detail object, then a single method call even from a configured handler still needs to be cascaded down to the right part of your view which may or may not be selected easily using instance tests, etc. In this case, it may be easier to define a local handler manager that be connected to the view or editor site (so it is deactivated when the part deactivates) but that can also be further controlled (such as the enablement state of specific handlers) directly in a view controller of some sort. In this sense, you need something like TextActionHandler but that works with real command handlers.

More later...

Popular posts from this blog

graphql (facebook), falcor (netflix) and odata and ...

React, Redux, Recompose and some simple steps to remove "some" boilerplate and improve reuse

Using wye and tee with scalaz-stream