If a topic is the result of some processing involving url parameters, the TOC does not work correctly. The links generated for the TOC do not reflect the url parameter that generated the topic, so when clicking on the link it puts you to the original topic, which may be meaningless.
Example: I generate a weekly report for all my staff from many topics, which results in a page
This topic includes a TOC. However, when clicking on a line in the TOC, it brings us to, say,
which is just a skeleton for the real page.
I tried to disable the linking by putting
tags around the TOC, but that did not work...
I guess the assumption of the author of TOC was that parameterised links are not idempotent (for example, the paramaters might have been passed in from a search form or similar). Off the top of my head I can't see why that should be so, but perhaps someone can see what I can't.
I think it is very clear to a user that when you click on a table of content entry, you should get to that section in whatever you are looking (if that section is there), not to a section in a document that you are not looking at.
Secondly, it appears to be a defect that one cannot turn off linking for the TOC using the
I implemented the following workaround: I added an "args" parameter to %TOC%. This parameter is then appended to the links generated for the TOC entries. Thus, clicking on the TOC entry will get you to the designated topic with the additional parameters supplied.
Maybe a better workaround would be to change the handling of the
default parameter to pull off the "?" parameters from there, but that requires some change in the TOC handling code.
Of course, the best thing would be to make TOC work correctly without these workarounds... This could be accomplished by fetching all the cgi parameters with
points to the query object, and then retrieving all the values by looping over this list. This would build up the args list mentioned above.... -- TW
Rewrote the TOC patch to get all the URL parameters and pass them on to the TOC.
Also had to fix a bug in
which had put the anchor before the URL parameters, thus causing the URL parameters not to be seen (at least on IE).
There still is a problem in that clicking an anchor presents the same URL in a different format than when sending data from a form, thus causing a reread of the topic.
Here are the variations:
- Sending parameters from form:
Actually, the original TOC also used
to separate the fields.
encodes the parameters, but even if not encoding, the browser changes the spaces to
Any idea of how to change what the browser does (either to avoid getting the
in the first case, or the
in the second)? -- TW
I don't think you can avoid that. Different browsers use different synonyms for whitespace and parameters. Besides, if the URL is the result of a method="GET" action from a form, how can you be sure the parameters will always be in the same order? I'm pretty sure it will be random, or at least browser-dependant.
Where is this patch?
I wanted to get this last problem solved. Right now the first time one clicks one has to reload because of the difference in appearance of the URL. I would like to avoid that if at all feasible... --TW
Addressed the issue described above. I also fixed a problem in the current code where the
is put before the URL parameters. Factored out a function
that is used both in
, for consistency.
Clicking on a TOC link now correctly uses any URL parameters that might have been passed into the page, and does not reload the page when staying on the same topic.
Added a unit test
. -- TW
While the change correctly fixes the
problem, it should be pointed out that the actual problem is that the
does not retain URL parameters. Having simple hand-made relative anchors like
in a topic and linking to them with
fails in the same way if the topic is used with url parameters. Note that TW
's fix is "robust" even if the base tag is going to be fixed some day. -- haj