Community
Participate
Working Groups
Several multi-page editors (JSDL, Queue Configuration, SLA) have/will be developed for the g-Eclipse framework. Following the discussion which was initiated in Bug#: 232253 and continued during the g-Eclipse Reading meeting, it has been identified that a generic checkstyle functionality for g-Eclipse editors is in need. The JSDL editor can utilize such check styles in order to enable/disable JSDL elements that are supported by each middleware. For instance, the GRIA middleware does not support all JSDL elements but the user is not aware of this. The JSDL editor does not provide any warning to the user for elements which are not supported - which results in the creation of "invalid" JSDL documents. On the other hand, the Queue Configuration editor (Operator Perspective) can benefit from such functionality for during the management of different Batch systems (PBS, LSF ,etc) which are/will be supported in g-Eclipse. My initial idea on the subject is to create a template XML file which will include generic XML tags such as: - Editor Name - Editor Scope ( middleware / batch system / sla) - Scope ID ( JSDL or GRIA or.. / PBS or LSF or... / ...) - Allowed Editor Fields This XML file can be used during the loading of each editor and based on its contents, the necessary editor fields can be enabled/disabled. A good idea is to also provide the functionality to end-users to create themselves such an XML file through a dedicated page in the g-Eclipse Preferences page. The above reflect my initial thoughts on this feature and which are not necessarily the most ideal or complete ones. Several issues arise such as 1) whether such an XML file should be VO bounded - i.e dedicated to one VO (see GRIA problem above), 2) where such a file will be kept in the workspace 3) will it be visible to the users so it can be exported /imported to another workspace. Hence, i would like to hear also your ideas or suggestions.
A few comments: - hopefully we can reuse this concept also for dialogs, not only editors (perhaps the case for ACLs). - no, we should not mix Grid concepts with this generic checkstyle stuff. Ie, the dialog/editor/whatever should be VO independent! or at most the middleware can open it with different checkstyle configurations to achieve different functionality, but we should not mix the vo concept in the generic-checkstyle declarations. - regarding your propose to allow users to configure it by themselves: ok, i would classify it a nice to have but really minimal prio. Anyway, such a feature would only make sense IMHO if the editors/dialogs/wizards can get less entries (ie, not only grayed out but also really get "smaller"). But changing the layout automatically in a meaningful way would be really complicated... - it would be necessary/nice to have not only - Allowed Editor Fields for disabling the whole widget but also some way to define - allowed values (in a drop down list for instance) - default value - some king of pattern validator for text fields?
Hi Ariel, I agree that the configuration page should be really low priority. Also i agree that the editor fields should be greyed out when the respective element is not supported. As for your suggestion on the default/allowed values, this should depend on the respective model's schema. The schema defines which are the allowed/default values. So far, the JSDL editor and the Queue Configuration Editor obey this requirements through SWT validators and i don't know how straight forward and time consuming is to change this. Thanks.
Created attachment 108181 [details] Screenshot with exemplary Problems View and error markers in editor Whenever I read the term 'checkstyle', I get a bit confused and associate the Checkstyle plug-in for Java with it. But that is not really what we want to achieve here. By reading your initial thoughts, it sounds like a dynamic editor, i.e. an editor that changes its behaviour according to a customising configuration file. While this approach seems to be feasible, I would go another way based on specific validators (e.g. standard JSDL, GRIA JSDL, etc.) that generate errors/warnings/infos and add them to the resource itself (here the JSDL file). I have to admit that this may not be as user friendly as your sketched solution at the first glance, but it sounds easier to me. It is another way of integration and IMHO is of higher value to the end-user. Hiding or disabling an editor input field, or providing a (middleware-specific) default value is not possible with my proposal, but by implementing specific validators you could check if a value is required, if the value makes sense and is allowed, if e.g. a required file exists, etc. and everything in a generic *and* in a middleware specific way. Did you already thought about this direction?
Hi Mathias, No, actually i didn't think of what you are proposing. But after reading your proposal i got into the following thoughts... 1) Does an end-user actually looks at the resource and it's content first and if so when/how many times ?? IMO the users rarely get to see the actual resource ...maybe they switch to the raw source only once or twice during the whole editing procedure of the documents. One of those times is at the end of the editing phase. And precisely, this is why editors exist...to hide the burden of writing a file manually (something that users don't line....) 2) Sure, a warning in the resource file will fire-up error markers in the Grid Project View....and the user will inevitably have a look in the source page. But what happens when s/he sees a warning saying for e.g. "Element: Candidate Hosts not applicable for the GRIA middleware" ??? Does s/he goes back in the JSDL editor, or any other editor, finds the elemenet causing the warning and tries to correct it? I believe using this way, it can be somehow frustrating and also we degrade the interactiveness our framework with the user. (In reply to comment #3) > Created an attachment (id=108181) [details] > Screenshot with exemplary Problems View and error markers in editor > > Whenever I read the term 'checkstyle', I get a bit confused and associate the > Checkstyle plug-in for Java with it. But that is not really what we want to > achieve here. > > By reading your initial thoughts, it sounds like a dynamic editor, i.e. an > editor that changes its behaviour according to a customising configuration > file. While this approach seems to be feasible, I would go another way based on > specific validators (e.g. standard JSDL, GRIA JSDL, etc.) that generate > errors/warnings/infos and add them to the resource itself (here the JSDL file). > > I have to admit that this may not be as user friendly as your sketched solution > at the first glance, but it sounds easier to me. It is another way of > integration and IMHO is of higher value to the end-user. Hiding or disabling an > editor input field, or providing a (middleware-specific) default value is not > possible with my proposal, but by implementing specific validators you could > check if a value is required, if the value makes sense and is allowed, if e.g. > a required file exists, etc. and everything in a generic *and* in a middleware > specific way. > > Did you already thought about this direction? >
I meant to answer to Markus and not Mathias....the habit of reading names too quickly. Sorry about that.
We had discussed a bit the "source file validators" approach in one of our EVO meetings (or was it Reading?) and the decision at that time was going for the "dynamic-editor" because of the reason Nicholas mentions, if the have a user friendly graphical editor, the user is not supposed to have to check the sources directly. But of course, having both the dyn-editor and the validators would be even better! ;-)
Created attachment 108196 [details] 2nd Example In that case my first screenshot - it was meant to visualise an example - has been misleading and counterproductive... -> I was not talking about the 'source' page of the multi-page editor and I agree that this is the page that most users won't use at all. But look at my other exemplary screenshot, taken from PDE 1. The resource 'MANIFEST.MF' is clearly marked as 'hey, here is something wrong' 2. The editor shows in its top line that '1 error has been detected' 3. The editor shows the exact location of the error and 4. (not shown) it would be possible to add a quick-fix to this error
Yes, of course that is very nice functionality. However we must remember that JSDL is a standard and the editor is an editor for standard JSDL. So IMHO -> disabling widgets in the editor makes it a bit more clear what is going on than adding these "validator tips" -> we cannot mark the jsdl file itself "red" in the project tree if it is pure JSDL even if it is not GRIA compatible. -> i would not mark things as errors but as warnings anyways, and on the title "This job description is currently incompatible with <MW-here>" Another Q'n that came to me: The new job description wizard can open the JSDL editor with the "validator". But what happens when the JSDL file is already there and the user opens it in the editor by simply double-clicking on it? Will we open the editor without any validator, or shall we preceed according to the Project we are in? (ie, opening a jsdl in a gria project will always open the editor with the GRIA validator)
Closing this bug, since the g-Eclipse project is not archived.
Closing this bug.
