Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [geclipse-dev] GRIA questions
Hi All,
 
The checkstyle approach sounds great to me. Of course I was not aware of any of this stuff when I made my original suggestions. This approach effectively produces the same end result for the user (i.e. some assistance in understanding how elements are supported by middlewares), so I say go for it!
 
Cheers,
 
Ken.

From: geclipse-dev-bounces@xxxxxxxxxxx [mailto:geclipse-dev-bounces@xxxxxxxxxxx] On Behalf Of Nicholas Loulloudes
Sent: 13 May 2008 10:44
To: Developer mailing list
Subject: Re: [geclipse-dev] GRIA questions

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

Back to the top