Summary: | [api] provide an extension point for registering URL handlers (was: Hyperlinks to builds should open in task editor) | ||
---|---|---|---|
Product: | z_Archived | Reporter: | Sascha Scholz <sascha.scholz> |
Component: | Mylyn | Assignee: | Steffen Pingel <steffen.pingel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | enhancement | ||
Priority: | P2 | CC: | googleclone, mik.kersten, shawn.minto, steffen.pingel |
Version: | unspecified | Keywords: | noteworthy, plan |
Target Milestone: | 3.7 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | 357738, 370186, 370504 | ||
Bug Blocks: |
Description
Sascha Scholz
2011-05-17 04:11:11 EDT
That's an excellent idea that we should definitely consider for the next release to facilitate linking between the different artifacts. I am not sure where this would go but my first guess is that this is a platform concern and should be provided in the commons on the bottom of the stack. Sascha, Steffen, we have multiple Hyperlinks for Attachments in the Bugzilla Editor. Maybe we can use this to! There is a similar issue with regards to the Hudson/Jenkins discovery notification and the notifications framework. Handlers are implemented in the ServiceMessageControl. As a result the builds view can handle links properly but the notification popup can not. It would be great to have a common mechanism. (In reply to comment #3) > There is a similar issue with regards to the Hudson/Jenkins discovery > notification and the notifications framework. Handlers are implemented in the > ServiceMessageControl. As a result the builds view can handle links properly but > the notification popup can not. It would be great to have a common mechanism. I believe that the notification popup uses a Label whereas the service message uses a Link control which can cause inconsistencies. I agree that we should have common renderer and handling mechanism for this. Please file a separate bug against Commons/Notifications to track that since it's not directly related to this bug. I have pushed a proposal to http://review.mylyn.org/231. Shawn, it'd be great if you could take a look and let me know what you think. I have pushed the changes to master. Leaving open as a reminder to document the change. URL handlers can be registered through the org.eclipse.mylyn.commons.workbench.urlHandlers extension point. Implementors need to extend AbstractUrlHandler which gets passed a location and returns a boolean whether the URL was handled or not. The first handler to return true wins. The invocation order is controlled through a priority that can be specified in the handler. Handlers with higher priorties are invoked first. I have added a org.eclipse.mylyn.commons.workbench.browser.UrlHyperlink class which implements IHyperlink and uses BrowserUtil.openUrl() to open hyperlinks in rich editors when available. Spam removed by droy 2012-05-01 |