Community
Participate
Working Groups
There are several use cases where a help resource href needs to be resolved into a URL so that it can be manipulated (opened, shown in a browser etc.). This task is dependent on the help system plugged in. I have added two methods to IWorkbenchHelpSystem: resolve and unresolve. The former takes a String href and returns a resolved URL according to the active help system. The later takes a URL and returns the original href if the first part of the URL matches the base URL. The changes I made are backward-compatible in that AbstractHelpSystem has default implementations of the methods. Our own help implementation (DefaultHelpSystem) implements these methods in a non-trivial way. Please release the attached patch because Intro needs it in order to be able to embed help documents inside Intro pages.
Created attachment 19251 [details] Added support for resolving help resource hrefs into URLs
What's the use case for unresolve?
The @return tags for AbstractHelpUI.resolve and unresolve should spell out the general contract, not the behaviour of the default implementation. The default implementation can be described in the body of the Javadoc comment (it already is), and "For backward compatibility," should be omitted. Also need to spell out the expected behaviour for non-web-app based Help UIs that may not be able to convert to/from URLs.
Rather than returning the original URL (as a string), unresolve should return null if it can't convert back, or throw an exception.
I've released the patch as-is, but am leaving this open to address the issues above (ideally before M6).
Every help UI implementation can resolve href - returning a 'file:' protocol is perfectly acceptable. 'unresolve' is used by the dynamic help in situations where an absolute URL received from a link in a browser need to be converted back into href. It is fairly easy to implement - the same prefix added to href to resolve it is compared to the URL and if matched, removed from the URL to get href. I will make other recommended changes.
Created attachment 19259 [details] Fixed Javadoc and returning 'null' for unresolve by default.
Created attachment 19260 [details] Modified patch with 'unresolve' removed. I had a change of heart regarding 'unresolve' method - I will call it directly inside help system for dynamic help view. The 'outside' users only need 'resolve' so no need to expose 'unresolve' for the general public.
Doug has done the submission for tonight, but I'll review the last patch tomorrow.
Patch reviewed and applied.
Closing. Dejan, could you please verify in the test candidate?
Negative - the build candidate still has IWorkbenchHelpSystem with the 'resolve' method.
Meant to say 'unresolve'.
I just checked out org.eclipse.ui.workbench from HEAD and the code looks good there. So it is probably just a versioning issue.
Yes, the changes only went into the 16:00 build.
