forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: Run, Forrest, run!
Date Sat, 06 Apr 2002 15:27:12 GMT
Hi,

Nicola Ken Barozzi wrote:

>From: "Konstantin Piroumian" <KPiroumian@protek.com>
>
>>What about a dynamic book.xml? Say, a book.xml that contains also some
>>transformer tags for document sorting/filtering etc.? Book.xml format is
>>rather limiting without an intermediate transformation to add also book
>>sections/chapters to the navigation menu.
>>Example:
>>
>><book-list>
>><book src="doc1.xml">
>><title><xdir:insert select="doc1.xml#/@title"</title>
>><!-- Some tag to insert chapters and sections here -->
>></book>
>><book src="http://www... .doc2.xml">
>><title>Some external book</title>
>></book>
>></book-list>
>>
>
>FS
>
>This can be done automatically.
>
>Content has to be defined in one place only, and the titles and sections are
>defined in the documents.
>I'm against putting this in the book, where it doesn't belong IMO as a
>concern.
>
{coming into this late and browsing 20 or so past posts}
How do you guys handle the promotions and user/owner management? In 
other words, is there a workflow? (I realize you chaotically have this 
now) For example can/do you have a hierarchical concept of ownership 
where there is a an 'apache-root-user'; each project has a leader; the 
leader establishes how to dole out pieces of the site to  sub-leaders; 
sub leaders dole out work to authors. Authors *own* content pieces. User 
roles are established down the hierarchy by the relative leader. A user 
can be in anŠnle authorized by a leader, but the will only affect 
things further down the hierarchy.

When the author believes a content piece is ready it is flagged for a QA 
generation. The author, and his leaders (up the hierarchy path) and the 
QA people can return it to 'editorial' - or - QA can bless it and pass 
it on (promote it) to a certification stage/site. At this point the 
content is locked and there is no need to touch it any more (of course, 
a leader can kick it back to editorial, if necessary). With this type of 
system you can whittle down the site as you work on it. Anytime the live 
site wants to update, it gets what it needs from the cert site. This is 
all done with content living in one location with the locking system at 
the config level. The site is constanly changing but all under control. 
A webservice checks to see if there are updates to cert and grabs them 
when it finds them.

Is this type of thing out of scope for this project?

best,
-Rob



Mime
View raw message