Community
Participate
Working Groups
This bug summarizes some discussions between Simon and Susan, and additional discussion on the 5/3 Orion call, etc. In bug 345622, we removed some of the content creation ("Getting Started") info from the index.html. The content was old/invalid, but we still wanted some kind of content for creating new projects that have content. The old "getting started" info was an extension point (orion.page.tasks), for plugins (such as the Maqetta/Orion integration plugin) to hook into our landing pagecreation with a link. But it turns out that what is interesting to most plugins is not generic "getting started" hooks, but instead a way to generate a project appropriate for their users. In bug 345622, we realized that we don't have all the answers yet to generic project creation by plugins, so instead we implemented some "canned" content generators that act upon the explorer root. But this will need to be generalized so that third parties can generate content. The question is whether this hook is tied to a file service or is really separate from a file service, or both. For example: 1) a file service implementor that is targeted for certain kinds of projects and has an alternate server (Jazz, etc.) could supply additional service metadata that give enough UI information to add "New" to a menu somewhere. They could name "new XXXX" or even have a branding icon in the metadata. 2) a plugin that is not dependent on any specific file service simply wants to generate content into a folder, and they don't really care what the file system is. They just want to dump some stuff in there so that the Orion can identify it as a project of a certain kind (ie, Eclipse project natures) and their commands will be validated against their content. For case #1, security is not an issue. The file service could implement file service calls that generate the correct content, and the only issue for us is having metadata that lets us expose the content creation in the UI. For case #2, security is the issue. We define "new xxx" metadata and some kind of template generation, but how does the content get into a particular file system? Do we create the folder and the plugin provides a zip file, for example? To support both cases, we need the notion of validating the "New xxx" extension against a file system to determine if it appears only for that file system, for any file system, etc. This decision making will affect the UI. In a single file system installation, the contributions from case #1 and case #2 could be combined in a "new xxx" menu and the user has no distinction between them. In a multi file system installation, it gets tougher to present this nicely, because some "new xxx" contributions cross file system boundaries, and some don't. And to further complicate things, even in a multi file system installation, the user might not view it as multiple file systems (for example, disconnected vs. connected)... All of this needs more thought.
need some story for 1.0
Talked to Simon about this. For 1.0, we think the best idea is some variant of approach #2: > 2) a plugin that is not dependent on any specific file service simply wants > to generate content into a folder, and they don't really care what the file > system is. They just want to dump some stuff in there so that the Orion can > identify it as a project of a certain kind (ie, Eclipse project natures) and > their commands will be validated against their content. > > For case #2, security is the issue. We define "new xxx" metadata and some > kind of template generation, but how does the content get into a particular > file system? Do we create the folder and the plugin provides a zip file, > for example? We'll have a "new content" service and its properties will be Name, Description Then there will be a service implementation that will either: - supply a URL for a blob that we need to slurp and unzip - supply a command id for a command that is run against a newly created folder - supply a URI template The "create content" UI will generate the buttons based on name/description. Whereas today, we autogenerate a folder and make up a name, we will prompt the user for the name of the new folder and give them a chance to confirm the operation. If we are bringing in some blob in a URL, we can show the link to the blob so that the user could take a look at it first if they want, or even change the target location of the import. We talked about defining all of this in terms of a new generic "import" command that could even be invoked from other places in the UI. If that's the case, then perhaps the service implementation *always* runs a command. Not sure. The main thing to ensure is that, like URL bindings, we never run a command without giving the user a chance to confirm it. Since these content generation buttons are contributed by plugins, they can never just "do the work" they have to get confirmation. I think I can implement most of this on the client side without much effort. I may need some server bits from John to achieve the "unzip from URL" part of it. We have the pieces (import from URL, unzip from uploaded file) but we would need "unzip from URL" unless we plan to implement a client side unzip. I'll work on this when I return from vacation.
part 1 of this bug is committed in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=e707eeae37a45bfe8fa8a8a0329c37c38b2e7a05 What I've done so far is remove the "canned" commands that were being put in the content list and we are now populating the list from an extension point, "orion.navigate.content". We define three content extensions in the pageLinks plugin (zip, SFTP, Hello world) and one in the git Plugin (clone). The shape of the extension point is: id: "extensionId", name: "Sample HTML5 Site", description: "Description that appears next to button" folder: "Hello World", // default name of the new folder command: "orion.importZipURL" // command to run against the new folder The biggest user change so far is that the user will be prompted to name the new folder. Plugins could also define additional parameters that need to be collected before running the specified command, and those parameters will be fed to the invoked command. What's left to do here is to reimplement "orion.importZipURL" as a generic zip slurping command. Right now it is still hardcoded to copy files from the Orion server.
(In reply to comment #3) > The shape of the extension point is: > id: "extensionId", > name: "Sample HTML5 Site", > description: "Description that appears next to button" > folder: "Hello World", // default name of the new folder > command: "orion.importZipURL" // command to run against the new folder Alternatively a plugin could define uriTemplate which means the button links to another page rather than generating a folder and running a command.
opened bug 389089 for the server part needed so that we can point to our sample site template by URL and import it. Once this is implemented, then anyone could provide a named site template and add it to the "create new content" list.
The basic mechanism is now done in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a9ab5b31df5b8b3ab62c89904eca03bfd375c30f The "sample HTML site" now lives in a zip file referenced by the pageLinksPlugin.html, which now defines several "orion.navigate.content" extension points. In that extension, you can point to an href or to a command, and you can optionally pass parameters to the command. The workflow and presentation of the plugin parameters is still pretty bogus. That will be covered in bug 387770
