Bugzilla – Full Text Bug Listing
| Summary: | [client] Extensible editor lookup | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Mark Macdonald <mamacdon> |
| Component: | Client | Assignee: | Mark Macdonald <mamacdon> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bokowski, eclipse.felipe, john.arthorne, susan |
| Version: | 0.2 | ||
| Target Milestone: | 0.2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Mark Macdonald
+1 I would want to write a single plugin (html page) that combines contributions to the navigator (e.g. new file type), and any customizations for that file type in the editor (e.g. syntax coloring, code completion). (In reply to comment #1) > I would want to write a single plugin (html page) that combines contributions > to the navigator (e.g. new file type), and any customizations for that file > type in the editor (e.g. syntax coloring, code completion). I actually just opened a separate bug about how to package up related contributions: Bug 345301. But if that's not a very interesting/complicated question, then maybe I'll just roll it into this bug. > Orion 0.2 M7 > > We need a way to contribute new editors for a file type. Minimally this should > let you > register a new file type and customize the href that is given to files of that > type in the navigator. (For example, you might want to associate .svg files > with a visual editor, not coding.html). > > Also to consider: > - Managing multiple editors that can handle a file type At one point we discussed that each file type would have a default URL that we lookup, and if there were multiples, we would choose a default and then provide an "Open With" grouping in the menu. For the life of me I can't find the bug where we talked about this. Note that the filecommands extension already has a mechanism for choosing what file types the command operates on and what the href is, so I would think we'd do something similar. > - Different actions (eg. "preview" rather than "edit") I think this can already be accomplished with fileCommands. I think the main difference in this bug is that we want to influence what the main link to the resource in the navigator does, rather than have the label/href appear in the actions column. Otherwise it's just a file command with an href callback. (In reply to comment #3) > Note that the filecommands extension already has a mechanism for choosing what > file types the command operates on and what the href is, so I would think we'd > do something similar. > > I think the main difference in this bug is that we want to influence what the > main link to the resource in the navigator does, rather than have the > label/href appear in the actions column. Otherwise it's just a file command > with an href callback. Hm, so it sounds like the main link to a resource may be just a particular type of fileCommand that the navigator visualizes in a special way? (In reply to comment #4) > (In reply to comment #3) > > Note that the filecommands extension already has a mechanism for choosing what > > file types the command operates on and what the href is, so I would think we'd > > do something similar. > > > > I think the main difference in this bug is that we want to influence what the > > main link to the resource in the navigator does, rather than have the > > label/href appear in the actions column. Otherwise it's just a file command > > with an href callback. > > Hm, so it sounds like the main link to a resource may be just a particular type > of fileCommand that the navigator visualizes in a special way? yeah, I was first thinking we could have a well known command id "orion.open" but that's not quite right, because command ids have to be unique. From a conceptual/command framework point of view, we could have a specific "group" to which we add these commands, and we know to look them up when hooking up the link. But I don't think plug-in writers should know this. So far, we tend to expose the semantics (editorActions, fileCommands) in the extensions and then map to commands, scopes, groups as appropriate. I like this approach so far. So maybe we just define another extension "openWithCommands" which has validation properties, etc. similar to the fileCommands. When the navigator code is processing the fileCommands, it could also define an "open with" group that is a submenu of the actions pulldown and contribute those commands there. The thing that's special/different than the other object-scoped commands, is establishing the default and hooking it up to link. Also, we probably wouldn't want to have an "open with" menu if it only contains the one thing that the link already does. I'd almost have to write the code to explain this further, let me know if you want me to get involved... Or...as you suggest. maybe we just have a property on the fileCommand that says it's an "editor." The trick becomes how to find these commands as we build nav links. Maybe we just stash these in an array and consult them whenever we are building links.
If we were to define an "Open With" command group inside the actions "More" menu, the default command framework behavior would be to check how many commands were in the group, and if there was only one, it wouldn't create a submenu. This would mean, though, that you would always have a redundant link in the menu. For example, if there were more than one editor registered:
More
Delete
----------
Open with ->
Code Editor
My Plugin Editor
Some Other Thing
----------
Git Log
Git Remote
More
Delete
----------
Code Editor
----------
Git Log
Git Remote
It's redundant that "Code Editor" appear there when the link does the same thing. But maybe that's not so bad.
So I guess a quick and dirty start is:
- add an "editor" attribute to fileCommands
- define a new "open with" group in the more actions menu and stick all editor fileCommands there
- keep a cache of the editor commands and when we are building the links, choose the first one to make the href
(In reply to comment #5) > So far, we tend to expose the semantics (editorActions, fileCommands) > in the extensions and then map to commands, scopes, groups as appropriate. Keeping with this pattern, I'll provide an "openWith" extension point, which gets mapped to fileCommands (with an "isEditor" flag like you suggested) behind the scenes. The one point that concerns me is using the command callback to generate the editor href. Instead of a callback, I was hoping to write this declaratively so the nav doesn't need to load the actual service just to find out where an editor lives. So for now I'll specify the editor href as part of the service properties. (In reply to comment #7) > (In reply to comment #5) > > So far, we tend to expose the semantics (editorActions, fileCommands) > > in the extensions and then map to commands, scopes, groups as appropriate. > > Keeping with this pattern, I'll provide an "openWith" extension point, which > gets mapped to fileCommands (with an "isEditor" flag like you suggested) behind > the scenes. The one point that concerns me is using the command callback to > generate the editor href. Instead of a callback, I was hoping to write this > declaratively so the nav doesn't need to load the actual service just to find > out where an editor lives. So for now I'll specify the editor href as part of > the service properties. that makes sense. the validation properties will tell you what kinds of files it applies to. In the command case, the item itself is often examined to compute the href (for example, item.ExportLocation or something like that). Since this just involves mapping file extensions, you can use the validation properties. It's sounding less and less like fileCommands, though conceptually very similar. (In reply to comment #8) With what I've got now, our default editor registration looks like: > provider.registerServiceProvider("openWith", {}, { > name: "Orion web editor", > href: "/coding.html#${Location}", > validationProperties: {Name: "*.(css|js|html|txt|xml)"} > }); I'm not totally thrilled with the string-substitution in the href, but it at least lets you refer to any property of the item to construct your editor URL. |