Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: niclas@envision.asiaconnect.com.my
Message-ID: <3951BFEE.E969D959@localbar.com>
Date: Thu, 22 Jun 2000 15:27:42 +0800
From: Niclas Hedhman <niclas@localbar.com>
Organization: Bali Automation Sdn Bhd
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Thoughts on a data-driven web site
References: 
 <F1E50D2E3D69D211A8F90008C7B1D64C05360AC4@lmoxch11.nsmg.veritas.com>
 <39513279.F3D1A611@apache.org> <39514DE6.5BFB2DEF@apache.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:

> I've been watching over this thread quietly but I have things to say.
>
> Different issues were raised:
>
> 1) Cocoon is XSP-centric
> 2) XSP is generation-centric
> 3) We don't have taglib filtering

I think an even bigger nerve has been touched in this thread.

Is content generation and styling at all related???

Look at it for a second. In Cocoon 1.0, we could take XML _files_, and apply
transforms/filters and then serialize it.

In that case, what is "Content Generation"??

Opening an editor of some kind and create the marked up content.

But in fact, even in those days, I might have a virtual XML file, which looked
static to Cocoon, but was in fact generated on the fly. But that was external to
Cocoon, and not part of its 'scope'.

Could it be that Cocoon's scope should be consolidated to its initial scope, and
extensions, such as content generation be spun off separately??

Personally I believe so strongly in small components, that I think it is
worthwhile considering. It would defintely simplify design in each of the two
scopes. I also know that the 'outstanding' argument against it would be
'performance'.
But to that, 'performance' is NOT everything. If it was, Cocoon would be
developed in C as an Apache Webserver module.

Comments??

Niclas