Community
Participate
Working Groups
******This bug discusses the Query2 filed under https://bugs.eclipse.org/bugs/show_bug.cgi?id=359414**** Hi, I have a use case here where I want to contribute an action to the editor toolbar, somewhere near the NEW FOLDER or LINK FOLDER actions which would actually say ADD DEPOT. A depot is nothing but a repository which houses the project artifacts. The action not linked to any editor or file type. Clicking on it would probably end up displaying a dialog for the login information and on connecting would display the depot artifacts within the Navigator. How do I achieve this is the question? Also, I have seen how GIT has been integrated with Orion but I don't have such a huge requirement right now where I create a whole new page with its own Explorer and almost an entire application. I would want to reuse the already existing Navigator. Thanks and Regards, Pradyut.
(In reply to comment #0) > ******This bug discusses the Query2 filed under > https://bugs.eclipse.org/bugs/show_bug.cgi?id=359414**** > > Hi, > > I have a use case here where I want to contribute an action to the editor > toolbar, somewhere near the NEW FOLDER or LINK FOLDER actions which would > actually say ADD DEPOT. I assume that you really mean the navigator toolbar, not editor, right? > A depot is nothing but a repository which houses the > project artifacts. The action not linked to any editor or file type. Clicking > on it would probably end up displaying a dialog for the login information and > on connecting would display the depot artifacts within the Navigator. How do I > achieve this is the question? Once in the navigator, would you expect that all of the "normal" actions (and their implementations) would apply to these artifacts? You could delete them, rename, open git status, etc. Or would you expect that you needed to have customized implemetations for these actions (or disable these actions). > Also, I have seen how GIT has been integrated with Orion but I don't have such > a huge requirement right now where I create a whole new page with its own > Explorer and almost an entire application. I would want to reuse the already > existing Navigator. We generally use the model "resource + task = page". We are intentionally trying to break the UI into task based pages so that we don't end up with a "super-navigator." That is why I asked the question about what happens to the artifacts
sorry, pushed "save to soon." continuing... We generally use the model "resource + task = page". We are intentionally trying to break the UI into task based pages so that we don't end up with a "super-navigator." That is why I asked the question about what happens to the artifacts once they are in the navigator. If there are "depot specific actions" that apply to things in a depot, then I really would encourage you to look at a separate page for this functionality. If the depot is just a mechanism to get stuff into an orion workspace and you want the normal orion workspace file/folder mechanisms to work out of the box, then putting something on the toolbar makes more sense to me, because it really is analogous to "Link Folder." Note also that "Link Folder" is only available at the workspace root. Can a depot be added anywhere in the orion server file system? I'm also cc'ing Simon, because he is doing work running alternate servers on the workspace. (I haven't looked at it yet to determine the UI implications). For example, WebDAV backed folders. If we end up with a "mixed server" mechanism in the navigator (whereby different folders are represented differently) then that is getting close to this use case as well. I've changed the title to say "navigator toolbar" but please correct me if I got that wrong.
Hi Susan, My replies to your queries above. Point 1) Am I referring to the Navigator toolbar......Yes..I am. Point 2) Would I expect all the "normal" operations on my artifacts. Yes. I would. All the operations such as Rename, Export as zip, New File etc make sense even for my artifacts which also will consist of files and folders. I would want to disable some actions such as SFTP Import and Export, if I could. But I don't care even if they remain. They don't really pose any harm to my use case. Point 3) Discussing the "resource+task=page" paradigm further, we haven't really thought about it from that point of view. But we have deliberated upon whether to create a new page or contribute to the existing ones. So we broke down our requirements into two sets, the first one being a small set which can be fulfilled using the existing pages i.e to just add a depot (or should I say Link a Depot as you suggest), view it's artifacts, sources and edit the same. This is analogous to the Link folder thing that we have on Orion. The second set is a set of more UI, resource and task intensive use cases which would warrant it's own page. If the user is interested in these advanced features, he will install the plugin that would contribute this page to his account. (BTW, can I compare a page to an Eclipse perspective???? If Yes, I would be a bit concerned here since I would not want to introduce eclipse complexities into Orion as long as I can avoid it). Having said that, I cannot really comment about the "page thing" until I understand it well enough!!! Talking about the Super-Navigator? Is it that bad a thing. Why don't we let the end user decide what he wants to see in his Navigator. Personally, I would want to see all my artifacts in one Navigator rather than juggling around pages. One more query regarding the resource+task=page algo. Can the same artifact behave as a different resource in separate pages. For example, a resource with a .html extension appears as a HTML file in the Navigator page whereas the same file may appear as a plugin in the plugins view. If yes, then wouldn't we end up with a lot of pages?? I mean do we have any guidelines published as to when (and how) to create pages?? Best Regards, Pradyut.
We definitely need to think this through in 0.4. Are you using the Orion file service concept for your depot? (I think I saw some email traffic about that.) If so, then the original request in this bug (for a link folder/new depot) action really generalizes (in Orion speak) to "Create a new folder using the Xxx file service." So I would imagine a solution where we look at the file services that are installed and invoke a new action based on those. This follows my general approach for looking for semantic extension points rather than exposing the command scoping completely to plug-ins. You mentioned "avoiding Eclipse complexities" and that is why I'm trying to hide the command framework from plug-ins. We want to give plug-ins well defined places to contribute function and for things that are complex, you move to your own page. Some day we may end up exposing command placement and scopes, but I'm trying to keep the command extensions larger grained than that. So...when someone defines a file service, they can define creation parameters that they need (see bug 358767) and we can put them in a "new folder" command. Does this sound reasonable to you? (In reply to comment #3) Ack on Point 1 and 2. > Point 3) Discussing the "resource+task=page" paradigm further, we haven't > really thought about it from that point of view. But we have deliberated upon > whether to create a new page or contribute to the existing ones. So we broke > down our requirements into two sets, the first one being a small set which can > be fulfilled using the existing pages i.e to just add a depot (or should I say > Link a Depot as you suggest), view it's artifacts, sources and edit the same. > This is analogous to the Link folder thing that we have on Orion. Good. I agree that I think all the extension points you need either already exist, or are documented in other specific bugs (like scoped editor commands based on extension, etc.) > The second > set is a set of more UI, resource and task intensive use cases which would > warrant it's own page. If the user is interested in these advanced features, he > will install the plugin that would contribute this page to his account. (BTW, > can I compare a page to an Eclipse perspective???? If Yes, I would be a bit > concerned here since I would not want to introduce eclipse complexities into > Orion as long as I can avoid it). Having said that, I cannot really comment > about the "page thing" until I understand it well enough!!! We don't think of the page as a perspective. I think it's smaller grained than that. A page is very focused on user task inside a workflow, and the various links and extension points are designed to move the user easily from task to task within the workflow. We are trying to discourage the idea of contributing "everything you need to do to artifact X" in the navigator. Instead, contribute a link to a particular task associated with artifact X and let the user easily go there. > > Talking about the Super-Navigator? Is it that bad a thing. Why don't we let the > end user decide what he wants to see in his Navigator. Personally, I would want > to see all my artifacts in one Navigator rather than juggling around pages. I think we agree on scope, I'm not suggesting you have your own navigator, given your comments in Point 2. We just need to let you contribute some links/commands to go to the more advanced stuff. > > One more query regarding the resource+task=page algo. Can the same artifact > behave as a different resource in separate pages. For example, a resource with > a .html extension appears as a HTML file in the Navigator page whereas the same > file may appear as a plugin in the plugins view. If yes, then wouldn't we end > up with a lot of pages?? I mean do we have any guidelines published as to when > (and how) to create pages?? We're working through all this. But in general, I could imagine that yes, you could edit an html file, you could open a plug-in editor for it if it were a plug-in, etc. Note we have the "open with" extension point so that there can be multiple ways to open a particular artifact from the navigator. Within the team, we debate page scope quite a bit. We try to err on separating tasks out as pages, but when that gets cumbersome, we often introduce more elements. For example the git status page includes compare, status, and log functionality, and this was debated quite a bit to get the right amount of function in a single page.
Pradyut, we had a discussion similar to the questions you posed in this bug. Please see bug 361856 and the screenshot in https://bugs.eclipse.org/bugs/attachment.cgi?id=205865 The thinking is that we could group "file systems" on the left and then the right shows the drilled down content. So you could imagine something like Orion Folders Foo Foo2 Git Repositories org.eclipse.orion.client dojo sfmccourt.github.com Depots MyDepot The depot creation UI would be triggered from this left hand pane. On the right side, you would contribute some "well placed" commands that make sense in the navigator. But for overall management/configuration of a depot, you would probably have your own page. We are going through this same exercise for 0.4. For example, why can't I "Switch Branch" when looking at a git folder in the navigator. That is a nav command that would be very useful. But creating branches, or deleting them, or adding remotes...that would be done from a "Git Repository" page. We are trying to come up with the right split...the "every day" actions are convenient to have from the navigator (or even the editor for that matter) but we don't intend to pile everything in there.
(In reply to comment #4) > Are you using the Orion file service concept for your depot? (I think I saw > some email traffic about that.) If so, then the original request in this bug > (for a link folder/new depot) action really generalizes (in Orion speak) to > "Create a new folder using the Xxx file service." > > So I would imagine a solution where we look at the file services that are > installed and invoke a new action based on those. This follows my general > approach for looking for semantic extension points rather than exposing the > command scoping completely to plug-ins. You mentioned "avoiding Eclipse > complexities" and that is why I'm trying to hide the command framework from > plug-ins. We want to give plug-ins well defined places to contribute function > and for things that are complex, you move to your own page. Some day we may > end up exposing command placement and scopes, but I'm trying to keep the > command extensions larger grained than that. > > So...when someone defines a file service, they can define creation parameters > that they need (see bug 358767) and we can put them in a "new folder" command. > Does this sound reasonable to you? Well, probably this is a pretty late response. Just back from a long vacation. Just to answer your queries above. Yes. We are using the orion file service concept to contribute our content to the navigator. Hence, something like "Create a new folder using XXX service would definitely help" I agree with you that we should not expose the command framework to plugins, both from the POV that it would be a bit risky probably and complex as well to work against it. And hence, the idea of defining the creation parameters while defining the file service definitely helps. I would be interested to know how you plan to expose the power of the framework and yet hide the complexities.
I'm marking this fixed as I look at what we've done in M2. We list the file systems in the left pane "super navigator", so that you could easily see that there is a "Depot" file system involved. We didn't put a "plug sign" in there, but you can navigate to your depot workspace from there, and then you could contribute an "orion.navigate.command" to create a new depot. So..please reopen if there is anything missing.
