Community
Participate
Working Groups
Variant - "infocenter" Eclipse help system Some organizations might prefer to let the user click the TOC synchronization button. Others (like ours) might want to auto-synchronize so the user has the TOC context at all times. Since both approaches have rationales, maybe the best approach for Eclipse would be to offer the option. In particular, Eclipse might offer a JavaScript function that an HTML content page could call to notify the runtime Eclipse viewer that it's displaying. Upon notification, the runtime Eclipse viewer could auto-synchronize the TOC. The Eclipse displayTocFor() function is almost adequate to support TOC auto-synchronization. Content pages can call parent.displayTocFor( window.location.href ); and, if the book is open, the TOC synchronizes. If the book isn't open, however, Internet Explorer 5.5 reports an error at org.eclipse.help.webapp/help.js on the line var selected = NavFrame.toc.selectTopic(topic); That problem could be filed as a bug if Eclipse help sanctioned TOC auto-synchronization as an optional feature.
There is always a trade-off between making things very customizable and also keeping them simple. One of the reasons we use JSP's was to allow others to take the code and adapt it for particular usages. This is our first pass at a web based help for eclipse and the current implementation is not the most clean, reusable or componentized. We should be gathering this kind of requirements from users like you, who both understand the technology and the end-user requirements and come up with a more flexible help implementation. For this particualar issue, you are making the assumption that you have control over the help content, so you can ask pages to call some functions. We chose the opposite approach, saying that the help system does not care what the content is or does.
After 2.0
Re-opening the bug...
Targeted for 2.1.
I released some code changes to support autosynchronization. The code isn't final, and I'd like to get some input on it. First, your proposal to expose some Javascript is interesting and, instead on relying on internal details (parent.displayTocFor(topic) ) I chose to add a method showTopicInContents() in one of our public Javascript files, org.eclipse.help/livehelp.js. Then, all the content files that need to autosynchronize would need to have something like <script src="../org.eclipse.help/livehelp.js"></script> <script> showTopicInContents(window.location.href); </script> inserted in the <head> section. Note the "../" may need to be replaced by more ../ paths, depending on the nested level of the document inside the plugin directory. We used the livehelp.js, as this was the javascript to be included for calling actions classes in the workbench. However, we could change its name to helpAPI.js (or something of that nature), which basically would be a set of Javascript API's into help. The original proposal to use parent.methodCall() is fairly reasonable, but I think it implicitly makes assumptions about the help webapp implementation. We can discuss this or alternate approaches, if including livehelp.js is too much trouble.
