Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: forrest-dev@xml.apache.org
Subject: strengths of Forrest versus Cocoon
From: David Crossley <crossley@indexgeo.com.au>
To: forrest-dev@xml.apache.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: 19 Nov 2002 15:59:26 +1100
Message-Id: <1037681967.19493.112723.camel@ighp>
Mime-Version: 1.0

A prospective client asked me a curly question the
other day. I am not trying to get forrest-dev to
do my work, but i think it is an excellent question
that we can all benefit from.

"When we are designing our application architecture,
how do we decide whether to use Forrest or to use
Cocoon directly?"

Gee, i was not too sure of the answer. So i am
checking with the experts. Anyway, i think it would
make a good FAQ topic for the Forrest/Cocoon docs.

It will help to define a use-case to get the discussion
rolling. It sounds like a typical case.

* Each XML metadata document describes a package of data.
* Use their own specialised DTD.
* Probably store the docs in an XML database.
* Publish the metadata in xhtml, pdf, raw xml.
* Search the xml collection, and display relevant docs.
* Static or dynamic? Probably need both.
* Later on, will need to edit xdocs via their browsers.

My short answer was to use Forrest, because it has extra
capabilities packaged around Cocoon. However, then i
started to get a bit worried about some things, such as:

Does Forrest, when used as a webapp, have enough flexibility
for tuning of the application? (As described at
http://xml.apache.org/cocoon/performancetips.html


Anyway, what are the benefits of Forrest and where does
one draw the line between them?

Yes, i do volunteer to create a Forrest document from this,
if people think that it is useful.

--David