From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-07-31 14:08:53
Jonathan Turkanis wrote:
> > If we do this, then it should be possible to do something like:
> > <span onclick = "follow_link(1.5)">Chapter 1.5</span>
>This would be embedded in an anchor element, to allow links to work on
>no-script browsers? I think this should work.
I'll see if I can get frames/tree_control working in Boost.Book and start
experimenting with the code.
> > With regards to the page refreshing, this happens when you select
> > anyway.
>Yes, but I was thinking that "sync" would be used relatively
>infrequently, whereas following links within a page is common.
> > Is it possible to use '#' instead of '?', so the browsers won't
> > refresh the docs.
>If we use Rene's idea of displaying the tree in the content frame,
>then yes (I think). Otherwise, the url with the correct fragement
>identifier won't be displayed in the address bar.
>Including the tree in the content frame is a big problem, though. When
>I replied to Rene I was mostly worried about download times when
>viewing the docs online. But if a large part of the docs eventually
>use trees, it could unnecessarily increase the size of the Boost
>distribution. We could use iframes, but this won't work for old
Sure. It would be a good idea to have a working XSLT for
Boost.Book/tree_control first so we can try out the various ideas.
>I'd like to focus on:
> 1. Providing a tree control which library authors can add to
> 2. Allowing docs generated with Boost.Book to have a built-in tree
>control, with automatic synchronization if possible
>1) is basically done, unless someone has an idea how to eliminate the
>need for [sync]
>2) is doable, with hitch that linking within a page causes a reload
>(unless I misunderstood your suggestion)
The main steps for writing the Boost.Book XSLT code are:
1. Disabling section ToC's;
2. Overriding the default ToC mechanism in favour of the tree control menu;
3. Providing "chunks" for the main frame page and the ToC page;
4. Iterating over the various sections and extracting the names of the
"chunks" to use as the links;
5. Modifying the way sections are generated if necessary to accommodate the
6. Anything I've forgotten.
>I think only time will tell whether it's more annoying to have to
>manually [sync] the documentation or to reload the docs when linking
>within a page. So I'd say two variants of 2) should be pursued: one
>which produces docs using the existing tree component, and one which
>produces auto-syncing docs.
Once the code is written it should be possible to play around with what it
generates to test the ideas that you and Rene are suggesting.
Want to block unwanted pop-ups? Download the free MSN Toolbar now!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk