Community
Participate
Working Groups
Build Identifier: eclipse-SDK-I20091217-0819-win32 We would like the ability to override the Help Contents menu action to point to a custom help system such as a web 2.0 help system. This would be done via an extension point. The help system will likely be local, but would have a different URL then the original help system. We may want to look at using the BaseHelpSystem interface for this solution, where the custom help is an implementation of a BaseHelpSystem Reproducible: Didn't try Steps to Reproduce: 1. Implement a custom help system 2. When Help -> Contents is clicked, show custom help system instead of Eclipse default help system 3.
Created attachment 157193 [details] Patch for overriding the help contents menu action This patch creates a preference for overriding the location the help opens to. If the preference is not blank, then the value in the preference is used.
Created attachment 158269 [details] Patch for overriding the URL the help system opens to - Extension implementation This patch allows for the help UI to be overriden by using an extension point. Tested dynamic help and verified that the show in external window also opens to the override URL when the extension is present.
This is an interesting idea but we need to to make sure that we provide enough API to allow such an effort to be successful, in particular the servlets which provide support for table of contents, index and search are not API. This would be a good thing to do in a future release but it is too late for Eclipse 3.6.
Created attachment 181336 [details] Patch for overriding the Help Contents action This patch implements overriding the Eclipse help system UI in the folllwong way: - AbstractHelpDisplay - an abstract class which provides two methods: @return String help home path public abstract String getHelpHome(); @return String URL translated for overriding help system public abstract String processHelpURL(String helpURL); - HelpDisplay updates - the existing HelpDisplay class was modified to extend AbstractHelpDisplay and the two methods above were implemented by using the existing Eclipse code for launching the help system and also processing help URLs. Also, a method createHelpDisplay() was added to pick up the non default configuration (help display from extension point), or use the default Eclipse HelpDisplay. - org.eclipse.help.base.display extension point - provide a class which extends AbstractHelpDisplay and implements the methods above.
Created attachment 181390 [details] Test case for help display implementation The test case is a plugin which implements the help display extension point.
*** Bug 320670 has been marked as a duplicate of this bug. ***
Thanks Jim, looks good. Just one comment from me, really. Unfortunately, processHelpURL(String helpURL) still seems a little ambiguous for API. We might need to identify what could be a part of this URL - and if we can identify it, maybe we should just be sending a set of properties instead of the URL? For example, the properties might include topic=/my.plugin/topic.html, lang=fr, scope=MyScope (so it is easier to read then parsing a String). Or maybe this is a non issue - if we build the ContentService for the Help API ( Bug 319907) to accept these standard help URLs, then processHelpURL can call the ContentService to get the correct content, and then display it according to their UI.
I have several issues with the patch: Major issues 1. The @since tag on AbstractHelpDisplay should be 3.6 ( the plug-in version of org.eclipse.help.base ) not 3.7 2. Looking at the API it seems that while it is sufficient to open a page at a known address, such as www.google.com it is not going to meet the needs of a custom help system if that help system needs to be able to read content from the servlets of the Eclipse help system. To do this a port and hostname are needed. 3. The extension point schema is missing the since and copyright sections Minor issues m1. There are warnings for unused imports in HelpDisplay.java m2. Having HelpDisplay implement AbstractHelpDisplay and then creating a new object of type HelpDisplay in getHelpDisplay() works but it seems like the code would be easier to read if there was an inner class which implemented AbstractHelpDisplay and contained just the two methods. Having a test case is useful but we may need a test case which exercises some of the capabilities that a real help system would use. I think that we need to construct a more realistic example before this code is ready to be committed.
Created attachment 181522 [details] Version 2 of patch, takes port and host This version of the patch adds a port and hostname to the getHelpHome() method. I will attach a test case which exercises these parameters. We still need to figure out how processHelpURL(String helpURL) will be used so a client of this extension point can know how to write the code. It probably also needs a port and hostname.
Created attachment 181523 [details] Updated test case which uses port and host parameters
Created attachment 181551 [details] Test case version 3
Created attachment 181552 [details] Version 3 of patch which includes host and port parameters and simplifies interface This revision changes the methods in AbstractHelpDisplay to closer reflect the kinds of calls that can be made, which are a) Get the url for the home page b) Get the url for the home page while showing a specific tab c) Get the url which opens help while showing a specific topic
Chris A, if you can review Version 3 of patch I will commit it.
(In reply to comment #13) > Chris A, if you can review Version 3 of patch I will commit it. It looks good, but like you said, we really need a good implementation to test this - and I do not have an implementation ready at this time. Maybe we can put this on hold for a short while...
This looks good - we should commit for now and if anything comes up we can make sure to get it in the next milestone.
Patch committed to HEAD, Fixed.
