Re: [geclipse-dev] GRIA questions

[Nicholas Loulloudes <loulloudes.n@xxxxxxxxxxxx>]

Hi Mathias, Ken, All,

Here are my comments....

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.
  

Remember that our initial design objectives were to develop an editor that would ultimately support and conform to the JSDL standard and it's extensions (POSIX, Parameter Sweep), as these have been defined by the JSDL working group. By adding more generic code to provide JSDL editor flavors for different middleware i somehow think that we are "shifting away" from the standard.

The editor must enable a user to manipulate all JSDL elements and attributes no matter what the "end consuming" system (middleware) might be (GLite, GRIA, ...). Currently this is what the editor does and no objections should be raised from the users side since the editor does what it is supposed to do....produce JSDL standard conforming documents.

Therefore, I strongly agree with Mathias concerning the addition of more generic code in the JSDL editor .

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.

The checkstyle and markers idea that Mathias has proposed here is quite interesting. Users will easily get an idea of
what elements are supported by which middleware and can decide whether to edit or even remove unsupported elements
from the JSDL documents. A yellow marker should indicate a warning (i.e "<jsdl:Executable> element is not supported by....")
and red markers should indicate an error (i.e an element not conforming to the JSDL standard).

I have to say that currently the JSDL editor includes a validation mechanism for elements that do not conform to the JSDL standard. These
elements are marked with a red marker in the JSDL source editor.

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

 

_______________________________________________
geclipse-dev mailing list
geclipse-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/geclipse-dev
  

Best regards,

Nicholas.

-- 
_________________________________________________

Nicholas Loulloudes
High Performance Computing Systems Laboratory (HPCL)
University of Cyprus,
Nicosia, Cyprus

Tel:  +357-22892663
Email: loulloudes.n[at]cs.ucy.ac.cy

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature