Community
Participate
Working Groups
Currenty it is not possible to use the EPartService to open a perspective without the modelService. The modelService is necessary to find the perspective because EPartService.switchPerspective() requires MPerspective. Would be nice to switch perspectives with only one service not a combination of both.
I'm not sure, since EPartService also requires the MPart to operate on (can't just use String IDs) PW
Lars, perhaps what we need to do is to start up a 'utilities' class that contains a number of useful patterns. Note that this class would *not* be 'API' but instead provided through the incubator and / or the marketplace. As you know I'm loathe to start back down the path of extending (tweaking) the existing API to provide extras that can already be done with the existing API. Paul's comment is valid as well, I'd prefer the API to be consistent. Why do we even have 'switchPerspective' ? Once somebody's found their perpsective ('persp') then... persp.getParent().setSelectedElement(persp) ...should be all you need to do the other code in 'switchPerspective' should be *reacting* to the model change so the API should be unnecessary (i.e. this would allow you to 'activate' a perspective using the Live Model Editor.
Eric, PartService can currently be used "standalone" except for Perspectives. I think it is a bad pattern, if one of our services can only be used together with another service. PartService has a method findPart(String) which allows us to a MPart based on a String. That allows us to use PartService without ModelService for parts. But for switching a perspective, the PartService cannot be used standalone. I think the most consistent approach is to have an overloaded method: showPerspective(String) showPerspective(MPerspective) For an existing example in PartService for this, see the showPart method: showPart(String, PartState) showPart(MPart, PartState) Alternative we should add a findPerspective method to the PartService.
(In reply to comment #2) > Why do we even have 'switchPerspective' ? It was added to implement bug 300742 PW
(In reply to comment #3) > But for switching a perspective, the PartService cannot be used standalone. > I think the most consistent approach is to have an overloaded method: > > showPerspective(String) > showPerspective(MPerspective) > > For an existing example in PartService for this, see the showPart method: > > showPart(String, PartState) > showPart(MPart, PartState) I was hoping we didn't have showPart(String, PartState) (I missed it on my scan through the system). I'd prefer that the model service finds and walks the model, and the part service provides higher level operations that manipulate the model ... not duplicate every method with a model object and a string id. PW
@Paul, but the services should be usable without each other IMHO. Why not adding a findPerspective(String) method? In this case the PartService would be usable without the ModelService.
(In reply to comment #6) > @Paul, but the services should be usable without each other IMHO. Why not > adding a findPerspective(String) method? In this case the PartService would > be usable without the ModelService. Actually, services should focus on one thing that's important, unless one service cannot function without the other (i.e. the keybinding service doesn't work without the command service). Tightly coupled services is why you can't decouple the 4.x workbench still. In our world, the model is king. The model service has the search facilities. Get the model element you want from there. The part service is supposed to add extra model manipulation to support our notion of part operations. I'm already not thrilled about having the part ID as a String in that interface. PW
Lars, what do you think of the proposal in comment #2 ? This would remove the interdependency *and* be more in the proper e4 style...
Eric, I'm not convinced by an utility class. I think the core services should be usable without non API classes. Also I think a switchPerspective method is a nice shortcut, rather than having to interact with the model directly. This is a very typical action and having to interactive with the model feel unnecessary complex for this task. I still think a public MPerspective getPerspective(ID) method would make sense in the PartService. Or a switchPerspective based on ID.
Lars, I think that using perspectives is leading you back into thinking the '3.x way' (where everything was done by ids and API). In 4.x only those operations that *cannot* be performed by manipulating the model should be performed using API. In this case there is no need to have the API at all if the code were written correctly in the renderers. BTW, which non-API classes are you referring to ? Both the Model and Part services are 'API' (as is the model itself)...
@Eric: you suggest to provide a non API util in Comment 2. I still think PartService should allow to search a Perspective (based on ID) or to open a Perspective with an ID. If I have to use the model element in the PartService both are very tightly coupled. I think the idea of the PartService was to provide a simple API for common things. I see this in my Eclipse 4 training. I it hardly possible to use the PartService without the ModelService.
After two years I changed my mind,I think the current API is actually consistent. You need the modelService to find models and the partService operates on this model element. Marking as WORKSFORME
Several of my customers have a need for this. Reopening.
New Gerrit change created: https://git.eclipse.org/r/60038
Gerrit change https://git.eclipse.org/r/60038 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=fcec63ca7a2965d036eb8d44f2eba8b1ae63534d
.
