Re: Workplace node and its API

Hi Svato,

Svata Dedic wrote:

> Hi, Vito et all,
>
> I am trying to hook another UI for Workplace in new projects; I 
> encountered some problems and I would like to make sure that I 
> understood the design right.
>
> It seems that o.n.api.projects.ide.Workplace represents an 
> organizational layer above o.n.api.projects.core.ProjectManager that 
> organizes known projects. Is that correct ?

Yes, it organizes projects visible under the Projects node on projects tab.

>
> I marked things I consider issues with an asterisk (*). Some of them 
> suggest that the organizational structure could be considered an 
> implementation detail, or a detail the API client should not care of. 
> In such case, should Workplace be in the API at all ? I think this is 
> the central question I would like to ask.

Well, I asked this question myself several times and I always ended up 
with the answer that, yes, the Worklpace should be in public API. I 
believe that it allows other modules to better integrate/extend the 
functionality provided by the projects/ide module itself. I would like 
to prevent ourselfs from doing the same mistake as core did with the 
Filesystem tab. This tab is implemented in core and is completely hidden 
from the API. Users were asking many times for having some kind of 
synchronization between the editor and Filesystems tab, i.e the edited 
file is automaticaly shown in the tree hierarchy of Filesystem tab (see 
Eclipse how does this nicely work in the real world). There is no API 
allowing to do this and we don't have this feature. This is just one 
example.

>
> If the organizational structure IS a public contract, then please see 
> the issues explained below:
>
> I saw there's a method open(ProjectDescriptor), which wraps a call to 
> PManager.open() and in addition links the project onto the Workplace 
> and a matching method close().
>
> * I did not find an API way how to list all projects linked onto a 
> Workplace; I learned that actions within the module call directly into 
> WorkplaceImpl that contains such function.

That's bad, I will add the getProjects() method into the Workplace class 
API.

>
> * I could not find a way to listen on Workplace changes -- e.g. when a 
> new project is placed onto the Workplace.

OK, this is probably another missing part. Could you describe some 
usecase where this is neccessary. Please, note that this notification, 
if implemented, will not inform you that some project was opened and/or 
closed. It will inform you that some project was started to be 
visualized on the Projects tab or that it was removed from this tab. Any 
code which really need to do something with opened/closed project should 
use the ProjectsListener and hook up the ProjectManager.

>
> According to Projects UI spec, the Workplace node may contain items 
> that are either
> - project groups
> - individual projects

Yes.

>
> * I could not find a way how to get list of project groups, how to 
> create or remove an existing one. There's also no API to access a 
> project group as a collection of projects.

I know, this is intentional. Ideally, the project group should be 
implemented as a project nesting other projects. But since we defered 
sub-projects for future versions the groups aren't still implemented 
this way. In fact, project groups don't need all these things which are 
really hard to implement like inheriting settings from the parent 
project etc. They are just stupid list of sub-projects, but even for 
this we need to do some changes in the infrastructure which we aren't 
able to do in this release. On the other hand when this will be done 
groups will be accessible like any other project from the 
Workplace{ProjectManager}.getProjects() functions. That's why I don't 
want to expose anything related to groups in the API now.

>
> * I could not find a way how to copy a project to a group, or 
> atomically move a project to a group from within the Workplace node or 
> from another group

Manipulation with group's content will be exposed by the group-nature 
when it will be implemented. Why is the atomicity important?

Hopefully I clarified at least something. I will answer the rest 
questions (more UI oriented) in another email allowing UI people and 
developers to join the right threads ;-).

-vita