On Oct 16, 2007, at 5:46 PM, Benjamin Shine wrote:


On Oct 16, 2007, at 12:22 PM, John Sundman wrote:


docs/src/build.xml copies the files necessary for the live nav
    app to run into the reference directory,. It overwrites
    the docbook-generated index.html; while this goes against
    100% pure docbook philosophy, I've decided that it's
    more appropriate to design and maintain our own table
    of contents and home page, than to convince docbook to do
    it for us.

Provisional approval here. One of the benefits of moving to 100% docbook is that we (theoretically) get a combined index of all docs (Developer's Guide, Reference, Deployer's etc), as well as lists of tables, lists of examples, lists of figures, etc.

I would like to know more about what's lost when we overwrite the docbook-generated index.html. If it's valuable info, but in raw form, perhaps we could rename it instead of overwriting it? And then at some point massage it into something really useful?

Or do I misunderstand your point?

There's an index, and there's index.html. index.html is the "landing page", which up until this morning was the 4.0, bogus- structured TOC. Now index.html is a frameset containing the left- nav app and welcome.html.

The index with all the unified good stuff - classes, tags, attributes, methods - is turned off because it made the build take 80 minutes -- unfortunately, I can't find *where* it's turned off. Reactivating the index isn't a priority for ringding, so, for now I'll punt, and leave it off.

I must correct myself -- we do generate a comprehensive alphabetical index, of the kind one would expect to find at the end of a paper book, under the title "Index." That comprehensive alphabetcial index is in the file doc/indexapa.html and it contains links to content in the developer's guide and the reference guide.

You can see this comprehensive index in the paperpie nightly build:
http://labs.openlaszlo.org/paperpie-nightly/docs/indexapa.html

(although, by the time you see this, a new build will have deployed, which might break the above link.)

-ben


Reply via email to