Community
Participate
Working Groups
Breadcrumbs are incorrect for pages used by two or more TOCs. When a topic is reused (used by two or more TOCs), the breadcrumbs at the top of the page are incorrect. Steps to reproduce: 1) Download TPTP 4.5 RC2 all-in-one package (http://www.eclipse.org/tptp/home/downloads/?buildId=TPTP-4.5.0RC2-200805271330). 2) Open the Help and select Testing applications >> Testing with JUnit >> Editing JUnit tests >> JUnit Test Suite Editor. 3) Note the breadcrumb is Testing applications > Testing plug-ins with JUnit > Editing JUnit Plug-in tests > JUnit Plug-in Test Suite Editor. This is the breadcrumb for Testing applications >> Testing plug-ins with JUnit >> Editing JUnit Plug-in tests >> JUnit Plug-in Test Suite Editor >> JUnit Test Suite Editor.
Several other examples: a. Editing Junit tests all pages under this belongs to 'Testing plug-ins with JUnit'(that because they are sharing the same resource) we can see the link tree at the top of each page b. Running a test belongs to 'Testing plug-ins with JUnit' c. Analyzing test results all pages including this page belongs to 'Testing plug-ins with JUnit' or 'Testing manually' d. Generating test reports belongs to 'Testing plug-ins with JUnit' or 'Testing manually'
Several other examples: a. Testing manually: Analyzing test results/Generating test reports share the place as a root with 'Testing plug-ins with JUnit' sometimes b. Test performance: Analyzing test results/Generating test reports belongs to 'Testing plug-ins with JUnit' or 'Testing manually c. Test performance: Running a test belongs to 'Testing plug-ins with JUnit'
*** Bug 249002 has been marked as a duplicate of this bug. ***
Is there any status on this defect? This defect is required for the TPTP product documentation, and our consumers.
I haven't done anything on this so far - it's not so easy to implement, here are some thoughts on it. The breadcrumbs are based on the href being passed in the request header, and if the same href occurs in multiple places they will end up with the same breadcrumbs, which are based on checking each book (which has a Hashmap of the hrefs it contains) to see if the page is in that book. One way to get different breadcrumbs for different instances of the same page would be to add parameters to the hrefs to disambiguate them but that seems like quite a lot of extra data to be adding to each href in the table of contents. The other possibility I can see is to use a two step process where the server looks through all the TOCs for an href and if it is found in more than one TOC the response contains javascript which will cause it to make an AJAX call to the server, identifying the selected node to get the real breadcrumb. I'm not convinced that including the same page in more than one TOC is the best way to present information, usually when a second book wants to refer to a page in a first book a hyperlink is used, even if it requires creating a page which contains little more than a title and that hyperlink.
(In reply to comment #5) > I haven't done anything on this so far - it's not so easy to implement, here > are some thoughts on it. > > The breadcrumbs are based on the href being passed in the request header, and > if the same href occurs in multiple places they will end up with the same > breadcrumbs, which are based on checking each book (which has a Hashmap of the > hrefs it contains) to see if the page is in that book. > > One way to get different breadcrumbs for different instances of the same page > would be to add parameters to the hrefs to disambiguate them but that seems > like quite a lot of extra data to be adding to each href in the table of > contents. > > The other possibility I can see is to use a two step process where the server > looks through all the TOCs for an href and if it is found in more than one TOC > the response contains javascript which will cause it to make an AJAX call to > the server, identifying the selected node to get the real breadcrumb. > > I'm not convinced that including the same page in more than one TOC is the best > way to present information, usually when a second book wants to refer to a page > in a first book a hyperlink is used, even if it requires creating a page which > contains little more than a title and that hyperlink. Thanks Chris for this update and explanation. In our case, we have two or more TOCs that have common content that we do not want to duplicate or link to since it breaks the flow of the documetation. Our common content is both referenced and linked (e.g. <link toc="toc/test_results_toc.xml"/>). I would consider moving the referenced content to a separate/linked TOC except links TOCs have the wrong breadcrumbs as well.
> I'm not convinced that including the same page in more than one TOC is the best > way to present information, usually when a second book wants to refer to a page > in a first book a hyperlink is used, even if it requires creating a page which > contains little more than a title and that hyperlink. We are also very interested in getting this problem fixed. We have exactly the same issues as Paul, where plugins are shared among different primary TOC's, so that the user doesn't have to know that the plugin belongs to multiple products (what we call the primary TOC's). Chris's suggestion of using a hyperlink on a static html page will not work for us. If we use an html page, the shared content will be excluded in the search scope unless the user knows which specific plugins to include in the search scope. Also, these html pages would have to be maintained manually when the content changes, e.g. plugins added/removed/renamed. Can you please let me know what the plans are for this bug?
It occurred to me that there is another possible way to fix or work around this bug, which is to leverage the fix for Bug 184787. In Eclipse 3.5 if an href has an anchor I am adding an additional parameter containing the lookup path of the element. Can you see if adding anchors (even if they don't exist in the document) to your hrefs makes the problem go away?
Can you give an example of how to use anchors in this case? I assumed that we can't use anchors because the nested plugin can only hook into one parent. From http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/ua_help_content_nested.htm: Other plug-ins can then contribute to the anchor from their plug-in. This is done using the link_to attribute when defining a toc. <toc link_to="../com.example.helpexample/toc.xml#postConcepts" label="Late breaking info about concepts"> <topic> ... </topic> </toc>
By anchor I meant an html anchor, such as <topic label="Main Topic" href="html/maintopic.html#A">
So is the test that when there is one topic file (say, example.html) that we want to use in two different places in the ToC, that we have: a. Two HTML anchor spots coded within that HTML topic file at the top of its body, like: <a name="A"> <a name="B"> b. In tocA.xml, its <topic> href has both the file and an anchor: <topic href="example.html#A" label="First occurrence" /> while in tocB.xml, its <topic> href uses the same file, but with the other anchor: <topic href="example.html#B" label="Second occurrence" /> Is that the idea?
Oh, sorry, I missed this part of comment8: that the anchors don't have to exist in the topic file. If I code a #anchor in the href for the <topic> element, but the <a> doesn't exist in the topic file, does clicking on that <topic> in the ToC still load the topic in the right hand side properly?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
