12.6.2 Linking secondary TOCs to primary content (deprecated)

The methods described in this section apply to Eclipse version 3.3 and earlier versions. For Eclipse version 3.4 and later versions, see §12.6.1 Linking primary content to secondary TOCs instead.

To link a secondary TOC to an anchor in the primary content (or in another secondary TOC):

[EclipseHelpOptions]

; TocLinkTo = path to another (secondary) TOC with anchor,

; such as ../anotherPlugin/api.xml#moreapi, for link_to attribute

TocLinkTo = ../path/to/anotherPlugin/otherTOC.xml#moreinfo

The value of TocLinkTo is used for a link_to attribute in the secondary TOC. The secondary TOC file must have a name other than toc.xml.

To specify where in the primary helpset a secondary TOC should appear, in your FrameMaker document insert an EclipseAnchor marker in the paragraph that immediately precedes the point where you want the secondary helpset linked.

You can use a marker either of type EclipseAnchor or of type EclipseLink. Marker content consists of the following: 

EclipseAnchor	TOC level number, space, anchor name.
EclipseLink	TOC level number, space, path to the secondary TOC file.

The TOC level number is an integer that corresponds to whatever level number you specified for primary-TOC entries at the same level; see §7.4.4 Setting contents levels for HTML-based Help. The anchor name provides a target for a link from a secondary TOC.

Which marker type you use depends on which scenario you anticipate:

Alternative or optional secondary TOCs

Alternative primary TOCs.

Alternative or optional secondary TOCs

If you do not know ahead of time which sub-module (if any) will be needed at a given point in a primary helpset, use an EclipseAnchor marker in the primary system. Each sub-module subTOC.xml must include the anchor name in its link_to attribute.

EclipseAnchor rationale

Suppose you are creating help systems to be deployed with Eclipse version 3.3 or earlier, and you do not know which modules any given customer has, so you ship separate modules to be merged. If you specify all possible modules in the primary helpset, using EclipseLink, the customer gets broken links for any missing modules. So instead, you use an EclipseAnchor in the primary helpset for each sub-module; the marker content is not rendered, but it tells the sub-module where to hook in. When the sub-modules are alternatives, you do not need to rebuild the primary system even when you create more alternatives; just use the existing anchor. You cannot do that with EclipseLink; you would have to rebuild the primary helpset with an added link every time you created a new alternative sub-module.

Alternative primary TOCs

If you do not know ahead of time into which system a given sub-module must fit, insert an EclipseLink marker in each of the alternative primary systems, specifying the path to the sub-module.

EclipseLink rationale

Suppose you have many standard components, but a new framework for each customer. Then it might seem more direct to use EclipseLink, and link from the primary helpset to the secondary explicitly.

---

> 12 Generating Eclipse Help > 12.6 Merging Eclipse Help projects > 12.6.2 Linking secondary TOCs to primary content (deprecated)