RE: Going live
"Anton van Straaten" <[email protected]>
| Newsgroups | gmane.lisp.scheme.plt.schematics |
|---|---|
| Message-ID | <[email protected]> |
Brent Fulgham wrote: > On 2004-05-26 10:08:12 -0700 Anton van Straaten > <[email protected]> wrote: > > > Not every topic would need a TopicOrder value - only those where the > > order is important. Topics like "Introduction" sections, for example, > > could get a 0 or 1. > > > > Can't you use the "nexttopic" field? I thought that's what it was for! That is what it's for, but TWiki queries, like the one that generates the RecipeIndex, aren't clever enough to use it, afaict. I originally planned to use the NextTopic field with the more comprehensive Scheme-based TOC solution described in AdminCookbookViews (partly coded in Sandbox.SchemeTOC). However, the hack I'm talking about could be set up much more quickly. I think the main reason for wanting more sophisticated TOC features is to support multiple views of the site, including a printed book or PDF version (and also possibly for multiple online views). For example, in the book case, we want to be able to render chapters linearly, one topic after another, without the existing chapter pages that tend to have a mix of text and TOC. But while the site is online only, I think we can get away with less. I don't plan to abandon the more sophisticated solution, but I don't think we need to hold up going live because of it. The existing NextTopic data won't go to waste - if I add a TopicOrder field, I'll convert the NextTopic data. The form data is just tacked on the end of the TWiki source files, in a tagged text format, so some grepping etc. will take care of it. Anton ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click