Community
Participate
Working Groups
Build Identifier: 0.5M1 Maqetta would like to use the Orion navigator UI as an embeddable component inside of various parts of the Maqetta product. What I'm talking about is the tree control that shows the list of files, allows file operations (delete, duplicate, rename) and allows double-clicking on files to launch editors. In my mind, this navigator control is basically the cloud equivalent of Mac Finder and Windows Explorer. As such, it needs comparable functionality as the desktop mechanisms provide. (In particular, Maqetta will need an icon view in addition to the list view that Orion provides today, but maybe the Maqetta team can help out with the icon view since we might be the first ones who need it.) Maqetta needs to expose this navigator control in the following parts of its UI: * After a user logs in, we will have a Maqetta landing page (aka home page) where the user will find various getting started info (e.g., links to samples, tutorials, docs, and videos) plus thumbnails of designs that the user has created previous. What I'm thinking is that Maqetta defaults to icon view, but user would be able to switch to list view. (Which is why I'm interested in embedding Orion file navigator.) * When user launches the Maqetta page editor to do drag/drop creation of UI mockups, we will want to have a file icon at the top of our UI which will show a large-size pointy popup (aka TooltipDialog), inside of which we would like to show the file navigator. * At various other points in Maqetta's UI, we need to post dialogs which include file navigators. For example, when the user changes the background-image property on a widget, we need to show a file picker dialog so they can choose an image from their workspace. We would like to use the Orion navigator control for showing the files in the user's workspace. Reproducible: Always
John, I think we will want to break this up into several different bugs eventually. What I'm hearing is this: 1) the existing navigator should be embeddable in different page/dialog contexts. This refers to the tree/table presentation in the Orion navigator, which operates on a particular file system (file plugin). Currently the navigator reads the URL to determine what installed file system its operating on. (Note we don't support double click, we use a link model.) 2) We'll need to figure out where the cutoff is between standard file commands (new, rename, delete) and other commands that might be useful (SFTP import, upload zip, etc.) 3) the existing navigator should support additional modes of presentation, such as icons or thumbnails. We would probably want to look at what dijit might offer in this regard. It might behoove us to offer the "file traversing component" in a way that it's easy to add new widgets underneath to render the system. This way, the maqetta team could possibly write an icon view, or use some existing library, but have the Orion workspace model be driving the content and commands. 4) file/folder picking should be supported with the same viewing modes. This basically involves building a modal picker/popup that returns the selected URL rather than linking to content.
I'd like to start progressing this in the next release, at least items 1 and 2. These are good use cases for some of our other architectural issues with respect to UI component lifecycle (bug 379567) and service lifecycle (bug 337740) and the general idea of how a widget interacts with Orion services that might not always be there. Libing, I know you have a lot of "common navigator bugs" as well so I assume we'll be working together in some way. I want to make sure we spend time on the shape of API and documenting the lifecycle. One interesting use case to help shape the API is putting the navigator inside an editor outliner. The navigator could hash on file names so that you could switch files in page. The file/directory prompter case is also a good "rehosting the widget" test case.
Susan, I am advocating that someone (either Orion team or Maqetta team) create a standard reusable UI component that has similar functionality to the Mac Finder (or corresponding dialog that appears with a File Open) and/or Win Explorer, but the key thing here is "similar functionality" but with original look/feel, and offer this to the Web community as a reusable component that other similar cloud apps could use. We have about 20 places in the Maqetta UI right now where we show a file dialog which we have currently implemented using a Dijit Tree widget, but we have none of the UI niceties, such as recently used folders, common "mount points" (e.g., user's root folder), ability to switch from icon view to list view (or other views). We might conclude we need 2 standard components: one for a navigator page, and one for popup dialogs. Even if there are 2 separate components, I expect they would share a good percentage of code. I'm not sure which team will get serious first with such an effort. I'm already in early discussion with the Maqetta UI folks, but we don't have any serious UI designs yet. I'm not sure how fast we will move. There is a chance we might find ourselves forced to implement something in the next few months out of necessity. We definitely need to include styling hooks into the component so that its look can be customized. Within next few months, we are restyling Maqetta and it is likely to end up with a very different set of visual styling approaches than what Orion has these days.
(In reply to comment #3) > Susan, I am advocating that someone (either Orion team or Maqetta team) create > a standard reusable UI component that has similar functionality to the Mac > Finder (or corresponding dialog that appears with a File Open) and/or Win > Explorer, but the key thing here is "similar functionality" but with original > look/feel, and offer this to the Web community as a reusable component that > other similar cloud apps could use. I think we have similar goals, John. We also have a directory prompter implemented on dijit tree that we'd like to get rid of. I'd like to see the same chunk of code used in both the "hosted by dialog" case and the "navigator on a page" case. The only thing that I'm not sure about right now is the thumbnail/icon view you talk about. We haven't had a case for it yet. Our nav/explorer code right now has the notion of pluggable rendering, but it's currently tied to the idea of a tabular format(it generates table rows), vs. say, a free floating left to right icon format. That's not to say it can't be done, but that we haven't had a need for it yet. So our first exercise will be to prove we can rehost our stuff in different contexts (dialog, popup, outliner, nav page) and put a proper API and widget lifecycle on it. That will happen pretty quickly after the 0.5 release. I'd be interested in having you guys trying it, providing feedback on the API and from there we could talk about the alternate rendering and how to accomplish that. Getting the stylesheet to a point that you can style it how you wish is a known requirement.
Step one is committed. http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=158e54693f20da856e40cff545eba26c07dec6e7 The main thing done in this first commit is to move all navigator page specific code out of the generic file explorer code and into a specialized navigator renderer. Clients can now create a "file explorer" and supply their own renderer to draw the files in different ways. The only service that the file explorer requires is the file service itself, so dependencies on surrounding Orion services (commands, content types, etc.) have been removed. The DirectoryPrompterDialog has been changed to use the generic mechanism so it now looks/behaves more like the navigator. This proves that we can rehost the basic FileExplorer component outside the navigator page. A mechanical change is that I'm grouping all explorer files in an "explorers" subfolder of orion so there were lots of module definition changes in consumers. A side effect of removing our reliance on dijit.Tree was uncovering a bunch of unstated dependencies on things that Tree was requiring. So, for example, we started to fail everywhere we used dojo.DeferredList without declaring it in our requires. There are still some implicit dependencies sneaking around, because I put the declaration in globalCommands and all pages pull that in. However Simon plans to get rid of use of DeferredList anyway in bug 389181. My next step is going to be an attempt to write an outliner for the editor that acts as a mini-navigator. That would be yet another use case showing the file explorer used differently. The API is not ready for prime time, but we are getting there. For example, the explorer/renderer life cycle is not quite right, and the code that creates the explorer currently has to build a selection service which probably could be done internaly. The code currently looks like this. Given a "path": var selectionService = new mSelection.Selection(this.serviceRegistry, "orion.directoryPrompter.selection"); var fileExplorer = new mExplorerTable.FileExplorer({treeRoot: {children:[]}, selection: selectionService, serviceRegistry: this.serviceRegistry, fileClient: this.fileClient, parentId: domId, excludeFiles: true, rendererFactory: function(explorer) { return new DirectoryPrompterRenderer({checkbox: false, decorateAlternatingLines: false, treeTableClass: "directoryPrompter" }, explorer); }}); fileExplorer.loadResourceList(path, true); Minimally we should be able to create the selection service internally and perhaps the treeRoot itself, so that the client is just supplying the file service, parent dom, and some rendering options.
There will be some API iteration done in RC1. Note that we now have the outliner and the prompter using the navigator, so the consumption is better, things are more generalized.
gone as far on this as we will go in 1.0 given we aren't declaring API for UI components yet.
moving milestone to 2.0 M1 for future triage.
We now have things pretty generalized within Orion, using the code in different pages and in dialogs. There is plenty of code cleanup/simplification we could do, but I think it should be done with someone trying to use it in a specific scenario rather than have us guess what would be best.
I've opened a tracking bug that discusses the different code factoring challenges in our current support. Attaching this one to that bug.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
