[
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