And another one missing further contributions.
Ken, Nicholas, Kasia, everybody, please comment ...
Mathias
Hi Ken, All,
> Personally, if I knew I was creating JSDL intended to be submitted to
> GRIA, it would be nice if I could select a GRIA "flavour" option,
which
> would then somewhat restrict the editors capabilities. This might be a
> plugin which could override the generic behaviour for the editor. For
> example, in GRIA we don't use the "Executable" element within the
"POSIX
> Application". It would be great if that was simply disabled during
GRIA
> JSDL editing. All the generic JSDL editor code would have to do is
call
> an "isSupported()" method on each element, in order to decide whether
to
> enable/disable this in the editor. So for the GRIA plugin, the
> isSupported() for an Executable element simply returns "false".
Once again I object to putting some generic code into the editor or
making the editor extensible in order to provide middleware-specific
implementations of it.
I have another suggestion on this that follows more the Eclipse way.
Think about the Java editor and Checkstyle. There only one Java editor
exists, no matter if you want to edit your Java file in Sun's way,
Eclipse's way or any other style. Nevertheless you can configure
Checkstyle to help you to produce Sun-style compliant code. Checkstyle
will then mark any non-compliant parts for you.
We could do the same for JSDL and the editor. We could provide an
extension point for JSDL-Validators that act like a Checkstyle setting.
That means that no editor fields disappear or are disabled but if
non-supported values are entered in the JSDL editor these field are
marked with yellow/red markers (and of course the source code is also
marked). These markers can have tooltips explaining to the user why
there is a mark. Furthermore these markers will appear in the "Problems"
view as all the other markers appear in there.
The marker concept is fully integrated into Eclipse. Its integration
starts in the editors and goes down to the resources themselves. So with
that we would have a general JSDL editor (like there are general
Java/C/C++/MANIFEST or whatever editors) and optional validators
provided by the middleware plug-ins that can be de-/activated on a
project-base (For my project A I would like to have the GRIA validator
active, for my project B no validator should be active) via the
project's properties.
We may then even think about standard validators that are tight to VO
types, i.e. if I am creating a project from a GRIA VO activate the GRIA
validator by default, but this may be another point of discussion ;-)
Cheers, Mathias
