forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Noels" <>
Subject RE: import of main site into forrest
Date Wed, 05 Jun 2002 15:41:58 GMT
> From: Stefano Mazzocchi []

> Don't want to rain on the party, but are you sure that
> xml-site/sources
> contains the *uptodate* sources from all the various projects? I'm
> pretty sure it doesn't.

Me, too. This is simply a showcase, and I've only translated the main
site docs, nothing subproject-specific.

> This you do it to actually generate the site
> or just as a
> test?

A test, and a starting ground for the main site.

> Yes, I wanted to raise this point earlier: there is no need
> to 'require'
> a document to have an author. For example, I dislike the fact
> that even
> the 'license.html' file has an author on top. It might lead to think
> that the person is the author of the content of the page, rather than
> the person who assembled the page from the content authored by other
> people.

+1, will make that optional if no-one objects to this.

> In those situations, it's much better to leave it out of the page.
> > - Auto-generation of mini TOC's - should this be
> parametrizable? TOCs
> > are generated now if sections exist within sections in a
> document, which
> > was good for the forrest docs so far, but suboptimal for the content
> > imported from the main site. On the other hand, these
> imported docs have
> > been abusing the DTD to obtain certain visual effects,
> IMNSHO - so we
> > could fix the docs, too.
> I was going to patch this on my local copy removing the 'isfaq'
> parameter (which semantically sucks!) and adding a 'minitoc'
> parameter.

Oops... you're wright ;->

> Now, I believe the best place for 'behavioral skinning'
> controls should
> be the book.xml file, which is sort of a high level site map
> (not in the
> cocoon's sense of the term, but in the original 'map of the
> site' sense)
> So, depending on the document, it's up to who links the
> documento to the
> book to indicate whether or not this document should have particular
> skinning behaviors associated. Examples might be:
>  1) minitoc yes/no
>  2) printable version yes/no
>  3) multipage yes/no
>  4) ???
> allowing us to set those behaviors in a single location and separating
> the concern from the document author simplifis the editor's job of
> providing the best visual coherence and usability for the entire doco
> corpus.

I like this idea, we need to think about this.

> > Please review the result of this little transition exercise and post
> > other issues you come across with.
> I'm offline so I don't have access (yet) to what you did, but I have a
> few comments since I spent yesterday afternoon making myself
> up-to-date
> with Forrest.
> Things to note:
>  1) the navigation path on top of the page is static. I mean, when you
> change page, the path doesn't change. We *must* fix this before making
> Forrest go live.

-0 - we can do this later on, too. This is another area which could be
touched by upcoming book.xml alternatives/additions, so we need to be
careful with this.

>  2) the tabs are fake as well. this is another big showstopper.

I've seen Bert has a solutions for this, we need to wait and

>  3) there is no DTD for .xgump and this makes the changes and
> toto DTDs
> obsolete. Having a complete DTD for xgump and removing the obsoleted
> DTDs is another showstopper.

Honestly, we don't have much dependencies on Gump. Build & project
automation is a very political area,  cfr. Nicola's remark. Some careful
thinking will be required.

>  4) the javadoc DTD is unused and it doesn't seem that nobody is
> interested in making it work for Forrest ATM. I propose to move it in
> the scratchpad area.
> Expect more things as I go along.

You're absolutely welcome :-)


View raw message