Summary: | [Help] Add support for resolving hrefs in the workbench help system | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Dejan Glozic <dejan> | ||||||||
Component: | UI | Assignee: | Dejan Glozic <dejan> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | CC: | eclipse, konradk, mfaraj, michaelvanmeekeren, n.a.edgar | ||||||||
Version: | 3.1 | Keywords: | api | ||||||||
Target Milestone: | 3.1 M6 | ||||||||||
Hardware: | PC | ||||||||||
OS: | All | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Dejan Glozic
2005-03-28 18:14:44 EST
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. |