RE: [boost] Re: Re: Re: Javascript Tree Control [was: SerializationMenu]

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
>"sync"
> > anyway.
>
>Yes, but I was thinking that "sync" would be used relatively
>infrequently, whereas following links within a page is common.

Sure.

> > 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.

Okay.

>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
>browsers.

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
>hand-written docs
>     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 
new control;
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.

Regards,
Reece

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/