forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: strengths of Forrest versus Cocoon
Date Tue, 19 Nov 2002 08:09:29 GMT
On Tue, Nov 19, 2002 at 03:59:26PM +1100, David Crossley wrote:
> 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

No reason Forrest webapps can't be tweaked just as much as Cocoon
webapps.  Projects can even specify their own cocoon.xconf and
logkit.xconf in ${project.conf-dir} (src/documentation/conf)

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

Forrest does make a pretty decent Cocoon starter kit.

If Forrest were made really modular, so that related XSLTs and DTDs were
packaged into individually downloadable chunks.. and Docbook was just as
easy to use as docv11.. what would be left in the Forrest "core"?
Probably not much.

Likewise, if Forrest is "Cocoon for project docs", why not have "Cocoon
for intranets" or "Cocoon for weblogs".  If Forrest invents a suitably
generic project 'seed' and config mechanism, why should it be limited to
seeding and configuring Forrest projects, and not other sorts?

Maybe Cocoon blocks will make most of today's Forrest obsolete.. :)

I suppose users will decide exactly where the Cocoon/Forrest dividing
line is.


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

View raw message