[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [geclipse-dev] Remarks and questions to eu.geclipse.info
|
Hello everyone.
1) First a very general point that I already discussed with Ariel.
Should the info plug-in be renamed to eu.geclipse.core.info? Ariel
voted +1, I did -1, but in the meantime I am at +1 :) Note that
renaming it would also mean to put the UI stuff into eu.geclipse.ui
rather than in a separate eu.geclipse.info.ui plug-in. Nevertheless
this is not that important, just wanted to mention it for the sake of
completeness. Let’s come to the more important points…
I am happy either way. I guess it depends on whether we want to reduce
the amount of the plugins.
2) The info plug-in defines an extension point, i.e.
eu.geclipse.info.infoService. What is the purpose of this extension
point? Do we really need this? I am convinced that this is not needed
since everything concerning model elements can be done with the core’s
extension points (at least this is what I believe :)
This extension point is used to define a info service. By looking at all
the classes implementing this extension point and I can get the info
service for the specific vo. The following code is used for example when
adding a info service to the project in GriaVirtualOrginisation.java
IGridInfoService infoService = InfoServiceFactory.getInfoService(
VO_TYPE_NAME, this );
addElement( infoService);
3) Furthermore there is a second extension point defined, i.e.
eu.geclipe.info.infoViewerFilter which is used – as far as I
understand – to plug-in the middleware filters available from the info
viewers action bar. Also here I would say this is not necessary, at
least if we are filtering not for middlewares (remember, we are
middleware independent, otherwise we would already have a middleware
extension point in the core) but for VO types (which brings the
middleware into g-Eclipse), i.e. GRIA, VOMS, etc. You could then get a
list of all available VOs by querying the VO manager and making use of
the IVirtualOrganization#getTypeName() method, this could give you the
filter’s name. Nevertheless I would recommend to not present filters
for all VOs but only for VOs that are currently assigned to at least
one project. Currently I also have a GRIA filter no matter if I have a
GRIA VO – or better info service – defined.
This extension is used in order for a specific info service to be able
to have its own filters. This helps modifiabilty and extensibility as
someone could add its own filter in the future for a specific middleware
quite easy. I have implemented filters only for the VO type currently,
but I think it is nice to make it easy for someone to add new filters.
4) Concerning the filters we currently have them spread over the
action bar (there are two, the “Show only filled information elements”
and the middleware filters). I would favour a solution following the
package explorer approach. There you have a dedicated “Filters…”
action under the views menu that opens a dedicated dialog containing
all available filters. Also note the “Select the element to exclude
from the view” field in that dialog. Wouldn’t that be a great addition
to our filters, having listed there the GLUE elements?
I have the two kinds of filters spread in the action bar because they
are independent. I think the way it is implemented now requires the
minimum amount of "clicks" on behalf of the user. I would favor to put
it in a dedicated "Filter" action if the action bar had many actions but
this is not the case in the glue info view. I think excluding glue
elements is not possible since they have a tree like structure. If you
exclude the parent node, then the rest will not appear too and that
would be confusing for the user.
Thanks,
Nick
