Bugzilla – Full Text Bug Listing
| Summary: | Favourites not associated with custom editors | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | James Brierley <james.brierley> |
| Component: | Client | Assignee: | Susan McCourt <susan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonm, susan |
| Version: | 1.0 | ||
| Target Milestone: | 2.0 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
James Brierley
I spent some time on this and unfortunately the change is getting too large for RC2. Issues: - the code we want is in navigatorRenderer. Ideally we should refactor this code so that navigator links can be gotten from a renderer without having to buy into the other stuff (like icons, grid behavior, command rendering) - I tried to copy only what was needed into the favorites renderer, which mostly worked once all the additional services (commandService, contentTypeService) were injected into the renderer. - however, the code in navigatorRenderer assumes the contentTypeService is an in-page synchronous service which is not the case here. Either the page needs to pass this service into the code that renders favorites, or else the code needs to be set up for asynch content type retrieval, which changes the structure of the code. All of this can be done, it's just moving a bunch of different code around, but this is not the small fix I had hoped it would be. It would be better to refactor the link rendering so that many different modules can use it and the page can set up synchronous services or asynch depending on the resolution of bug 337740 (see bug 337740 comment 15.) We have another case now, where Anton wants to show nav-like trees in the projects page and have them open with the same links that navigator would use. I'm thinking that rather than force clients into using any particular renderer, we could have some kind of utility method that generates the links and does lookup, so that this can be used in all kinds of presentations. And I can probably then set the link href asynchronously which solves the content type dilemma (I think). Fixed in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=fbaf1de3740d83d90de427c8f4803df4dcb27f22 We now have a helper method exported from orion/explorers/navigatorRenderer that will render a navigator-style link, complete with the correct editor and icon that indicates the content type. The favorites pane is using this helper, and is able to render links that now open the right editor. Anton, you can use this helper from your project tree. The API is mNavigationRenderer.createLink(folderPageURL, item, idPrefix, commandService, contentTypeService) So, if you want the folder links on the project page to go to the navigator, you would use something like mNavigationRenderer.createLink(require.toUrl("navigate/table.html", item, "", commandService, contentTypeService) Please note that the commandService must be the in-page command service that you instantiated on the page. It cannot be the asynch service in the registry. I'm not completely happy with this odd limitation, but it's because of the way we retrieve open with commands, which I'm not going to change. However...given that the long term direction in bug 390356 is to make the command service a synchronous helper, I'm okay with this. There was a problem in the fix, in that you have to have the open with command extension processed and added to the command registry before this will work. I updated the doc to state this explicitly. Changed navigator so that the favorites list is generated after this happens. When I first did this fix, I saw it working, but that was because any favorites added once the page was up at the open with commands, but the initial rendering did not. Anton, what this means for you is that your page needs to register all the file-based commands (including those extensions). You'll need the fileCommands module and fileCommandUtils.createAndPlaceFileCommandsExtension Note that you would need this anyway to support any navigator file-based commands. You'll want to make that call before you try to render your tree. (See table.js). |