Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ease-dev] Scripts location and parsers

Hi Guillaume,

the code to attach context menus is rather old and currently broken, but you figured that out already. In fact we are working to extend that approach a bit. Instead of contributing to context menus only, we want to contribute to any menu and toolbar available in the system.

But step by step:
Previously there existed a nature to detect projects to parse. This mechanism was completely replaced by locations you can register in your preferences. Thus allowing to register any folder within the workspace, the file system and at a later stage everywhere you can create URIs for (eg: svn://, http://, ftp://, ...). There exists a service that you may query for scripts found on such locations:

final IRepositoryService repositoryService = (IRepositoryService) PlatformUI.getWorkbench().getService(IRepositoryService.class);

repositoryService.getScripts() returns the found IScript instances.
An IScript now has a method getParameters() which will give you a map of key/value pairs found in the script header. The header is defined as the first comment within the file and has to be located before the first line of code. Check out JavaScriptHeaderParser for details. Each supported language comes with its own parser (I guess you are interested in python).

From my point of view o.e.e.storedscript is obsolete by now, as the new IRepositoryService replaces the modeled classes. I still left it in as a reference when I am going to re-implement the context menu stuff. If you are going to work on this (highly appreciated!) I'd suggest you put your code directly int o.e.e.ui (packages "metadata" and "scriptuigraph" are also not used right now).

For UI integrations I already started to code UIIntegrationJob which monitors scripts (as they may appear and vanish during runtime) and deals with adding/removing them from menus. This is work in progress and only works partially right now.

As for the context menus we had a quite elaborate expression language developed with xtext to create powerful expressions like the "visibleWhen" stuff in the Plugin editor of eclipse. Still I think this was far too complex for users. I would suggest to implement a simper version for script keywords. Something like:

/**
* context-menu: instanceOf(java.io.File)
**/

or

/**
* context-menu: adaptsTo(java.io.File)
**/

As this was mainly an ATOS use case I am not sure if such simple expressions would be sufficient.


Finally regarding getSelection(): the UIModule comes with 2 methods on selections. I know that ATOS used an additional extension point to adapt selections, but maybe the simpler, existing methods would be sufficient.


HTH
Christian



Back to the top