You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Steven Noels <st...@outerthought.org> on 2002/06/25 23:17:54 UTC

[Fwd: Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)]]

Nicola, it seems Ovidiu is building what we were trying to describe this 
afternoon in our chat.

Ovidiu, this is one of the current missing links for Forrest.

All, Nicola & I came to the conclusion that we need a live Cocoon 
instance for true experimentation on collaborative webbased editing for 
documentation, and this should be part of Forrest. If we can't convince 
infrastructure@apache.org to set it up on nagoya from the beginning, my 
company is currently investigating whether we could sponsor this (i.e. 
colocating a dedicated box for this purpose).

Regards,

</Steven>

-------- Original Message --------
Subject: Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't	suck   ( 
Re: [RT] Flowmaps)]
Date: Tue, 25 Jun 2002 09:11:57 -0700
From: Ovidiu Predescu <ov...@apache.org>
Reply-To: cocoon-dev@xml.apache.org
To: <co...@xml.apache.org>
CC: <da...@nada.kth.se>

<bigsnip/>

I started working on a simple documentation system which allows
documentation to be published, and give user the ability to add notes to
each page. I said this in the past too, I really like the way the PHP
documentation system is setup. For an example check out:

http://www.php.net/manual/en/language.constants.php

I want to implement a similar system using Cocoon, flow scripts and Castor
as a mapping tool between a relational database and Java objects. This is a
non-trivial example which I hope shows how the separation of concerns is
enforced in this design.

Regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


Re: [Fwd: Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)]]

Posted by Steven Noels <st...@outerthought.org>.
Michael Wechner wrote:

> We are currently migrating all our existing documentation for Wyona from
> plain HTML into xdoc. We started to implement Wyona to make the 
> documentation editable and publishable with Wyona.

Very cool.

> We are currently playing around with JCVS in order to not just
> publish the documentation on the web, but also to use it together
> with CVS.
> 
> I think the idea which some of you had, doing annotations by email
> is a very good idea, because you don't need a dynamic server (Cocoon 
> instance) for the "public". But of course for the backend for
> those who really want to edit/publish documentation in the WYSIWYG style
> (for instance committers) it is necessary to have one.

Yep, I found most of the mail-based solutions basically a hack. We 
should create modern software :-)

> We would very much like to contribute to the forrest (and Cocoon 
> project: though, I still owe Stefano an answer on the XInclude 
> Processor) project and if you (e.g. Ovidiu) can need our help, plz just 
> tell us.

Thanks Michael!

</Steven>

-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org


Re: [Fwd: Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)]]

Posted by Michael Wechner <mi...@wyona.org>.
We are currently migrating all our existing documentation for Wyona from
plain HTML into xdoc. We started to implement Wyona to make the 
documentation editable and publishable with Wyona.

We are currently playing around with JCVS in order to not just
publish the documentation on the web, but also to use it together
with CVS.

I think the idea which some of you had, doing annotations by email
is a very good idea, because you don't need a dynamic server (Cocoon 
instance) for the "public". But of course for the backend for
those who really want to edit/publish documentation in the WYSIWYG style
(for instance committers) it is necessary to have one.

We would very much like to contribute to the forrest (and Cocoon 
project: though, I still owe Stefano an answer on the XInclude 
Processor) project and if you (e.g. Ovidiu) can need our help, plz just 
tell us.

Thanks

Michael




Steven Noels wrote:

> Nicola, it seems Ovidiu is building what we were trying to describe this 
> afternoon in our chat.
> 
> Ovidiu, this is one of the current missing links for Forrest.
> 
> All, Nicola & I came to the conclusion that we need a live Cocoon 
> instance for true experimentation on collaborative webbased editing for 
> documentation, and this should be part of Forrest. If we can't convince 
> infrastructure@apache.org to set it up on nagoya from the beginning, my 
> company is currently investigating whether we could sponsor this (i.e. 
> colocating a dedicated box for this purpose).
> 
> Regards,
> 
> </Steven>
> 
> -------- Original Message --------
> Subject: Re: Use Cases [was Re: [RT] SpitScript - B-Logic that 
> doesn't    suck   ( Re: [RT] Flowmaps)]
> Date: Tue, 25 Jun 2002 09:11:57 -0700
> From: Ovidiu Predescu <ov...@apache.org>
> Reply-To: cocoon-dev@xml.apache.org
> To: <co...@xml.apache.org>
> CC: <da...@nada.kth.se>
> 
> <bigsnip/>
> 
> I started working on a simple documentation system which allows
> documentation to be published, and give user the ability to add notes to
> each page. I said this in the past too, I really like the way the PHP
> documentation system is setup. For an example check out:
> 
> http://www.php.net/manual/en/language.constants.php
> 
> I want to implement a similar system using Cocoon, flow scripts and Castor
> as a mapping tool between a relational database and Java objects. This is a
> non-trivial example which I hope shows how the separation of concerns is
> enforced in this design.
> 
> Regards,