[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [geclipse-dev] Remarks and questions to eu.geclipse.info
|
Dr. Mathias Stümpert
Project Coordinator
g-Eclipse Project (IST-034327)
Hi Nick,
> I am happy either way. I guess it depends on whether we want to reduce
> the amount of the plugins.
So since nobody else seems to be interested in this discussion and we have 2 +1s (Ariel and me) let's rename eu.geclipse.info to eu.geclipse.core.info and put the ui stuff into eu.geclipse.ui then!
> 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.
Bad idea! Actually you are bypassing our model with this approach. An info service is a model element. These elements are not defined by themselves but their creators are defined (via eu.geclipse.core.gridElementCreator). The reason for this is that the grid elements most likely do not have standard constructors and a createExecutableExtension(...) will then fail. On the other hand how can an info service have a standard constructor? Does it not at least need an endpoint reference (URL or File or whatever) where to get the info from?
Nevertheless, if your only use case is to get the info service for a specific VO then IVirtualOrganization.getInfoService() should do what you want. If you would like to get this for a specific VO query the VO Manager for this VO.
> 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.
Ok, this may make sense. Nevertheless I am still not sure that we really need this. The info viewer is based on a proprietary model (GLUE). So the information there will not really change for other middlewares in the future (I guess there is not extension point for changing the viewers content, right ;-). So that would mean it should be possibly to define all reasonable filters based on GLUE (and our model) without taking any middleware specific stuff into account. Am I wrong?
> > 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.
No further comments here, I stick to my argumentation. Any other comments?
> 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.
Ok, I agree here, doesn't really make sense to filter anything here.
Cheers, Mathias
