Bugzilla – Full Text Bug Listing
| Summary: | extension point for plugins to contribute new content to workspace | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Susan McCourt <susan> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | grant_gayed, john.arthorne, ken_walker, simon_kaegi |
| Version: | 0.5 | ||
| Target Milestone: | 1.0 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 389089 | ||
| Bug Blocks: | 378755, 397768 | ||
|
Description
Susan McCourt
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 |