forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Piroumian, Konstantin" <KPiroum...@flagship.ru>
Subject RE: [UPDATE] Last call to get new documentation stylesheets
Date Thu, 21 Mar 2002 16:38:46 GMT
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org] 
> From: "Piroumian, Konstantin" <KPiroumian@flagship.ru>
> 
> > From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> > > does anyone have an idea on what is the best way to tell Cocoon 
> > > which skin to use? I use a skin/{1}/blablabla type of URI 
> to get the 
> > > correct file, but how do I
> > > get the {1} parameter there in the first place?
> >
> > Should it be in the URL?
> 
> Now that I think of it, it is already in the url now...
> 
> jakarta.apache.org
> xml.apache.org

What about sub-projects? Say: jakarta.apache.org/avalon or
xml.apache.org/cocoon? Can they have their own skins or not? 

And relying on the host name to select the skin is not a good choice. I
think that skins should be configured somehow internally.

> ...
> 
> But what contract do we want Forrest to have?

It should be cool ;)

> 
> > Maybe it's better to have skins configured in
> > sitemaps? Ok, it's not good, in that case every project 
> should provide 
> > its own sub-sitemap with configured skins... Just an idea.
> > >
> > > It has to work both with CLI and webapp based (for the future).
> >
> > Please tell me if you get working CLI for my stuff.
> 
> Of course :-)
> 
> Tell me one thing.

Yeah...

> 
> Now I have my local copy of Forrest produce both 
> jakarta-style and xml-style docs using the usual nested 
> book.xml site structure, and I want to add your stuff.
> 
> What is the future documentation structure going to be?

As we decide. That's why I wanted to add my stuff to CVS to start this
discussion.

> 
> In your example all the structure def is in one file:
> 
> <book label="Area 1" uri="book1"/>
>     <book label="Area 2" uri="book2"/>
>     <book label="Area 3" current="current" uri="book3">
>         <page uri="page1" label="Page 1"/>
>         <page uri="page2" label="Page 2"/>
>         <chapter uri="chapter1" label="Chapter 1"/>
>         <chapter uri="chapter2" label="Chapter 2"/>
>         <chapter uri="chapter3" label="Chapter 3" current="current">
>             <page uri="page31" label="Page 3.1"/>
>             <page uri="page32" label="Page 3.2"/>
>             <section uri="section33" label="Section 3.3" 
> current="current">
>                 <page uri="page331" label="Page 3.3.1"/>
>                 <page uri="page332" label="Page 3.3.2"/>
>                 <section uri="section333" label="Section 
> 3.3.3" current="current">
>                     <page uri="page3331" label="Page 3.3.3.1"/>
>                     <page uri="page3332" label="Page 3.3.3.2"/>
>                     <page uri="page3333" label="Page 3.3.3.3" 
> current="current"/>
>                     <page uri="page3334" label="Page 3.3.3.4"/>
>                 </section>
>          ...etc
> 
> Is this what we are going to have as a site structure?
> One unified file?

It's not much different to book.xml, just a multilevel book. While book.xml
is tied to the directory structure and points to resources in the current
directory, this index menu can be generated depending on the request params
from either directory using Directory generator or book.xml(s) or one
unified index.xml.

> 
> AFAIK, we have nested book.xml files, an alternative by 
> Steven (still nested
> files) and some topicmaps FUD.

As I could get, Steven proposed something like an index file for the site,
including nested levels. Am I wrong, Steven?

> 
> - The book.xml stuff is old but tried and tested, and we 
> would have little difficulty with integration with current 
> projects, and give users a very low barrier to entry. We need users.

But book.xml stuff is hard to maintain and update.

> 
> - The alternative from Steven doesn't seem to add particular 
> semantics; we could as well enhance current book.xml, nes pa?

This is what I've done, although with different syntax, but the meaning is
the same.

> 
> - Topicmaps are very cool, but if noone sends some concrete 
> patch, we might as well leave them for Forrest 2 or integrate 
> them later, as a modern book-list.

Agree.

> 
> So, to get stuff going quick, my BIG +1 goes to use the 
> current documentation method, while enhancing it where needed.
> 
> This way the old docs would work without modification and new 
> ones have additional features.
> 
> Does this make sense?

No comments. Still thinkin...

KP

> 
> --
> Nicola Ken Barozzi                   nicolaken@apache.org
>             - verba volant, scripta manent -
>    (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 

Mime
View raw message