Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <43DE4828.1040005@apache.org>
Date: Mon, 30 Jan 2006 18:08:56 +0100
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] The environment abstraction, part II
References: <43D7F616.5060909@nada.kth.se> <43DBBC6E.20401@apache.org>
 <43DD1A8C.8070809@apache.org>
In-Reply-To: <43DD1A8C.8070809@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Sylvain Wallez wrote:
> 
> Sorry, what do you mean by "web framework"? Isn't it already one? Or do 
> you mean "servlet"?
> 
Cocoon is currently a mixture. It's mostly used as a web framework
through a servlet, but for example if you're using the cli you don't
have a web framework or a web server or something like that.
Now, because of this, we have the environment abstraction. And I think
we can remove that completly making Cocoon just a web framework which
always has a servlet environment including listeners and filters etc.

>> Now, we have currently two other environments: cli and portlets.
> 
> There's also BackgroundEnvironment for background jobs.
True, but as that one is running "inside" Cocoon it shouldn't cause
problems either.

> Hmm... Struts and Cocoon are on the same level, as they handle the 
> request. Spring (its container part) is more to be compared with our 
> ECM. So although setting up ECM as a context listener would make sense, 
> Cocoon itself must remain a servlet to be able to handle requests.
Yes, it can remain a servlet (although it might not need to be, but
that's another topic). Why not, for example, calling pdf generation from
let's say Struts?

Carsten

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/