Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <43DBBC6E.20401@apache.org>
Date: Sat, 28 Jan 2006 19:48:14 +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>
In-Reply-To: <43D7F616.5060909@nada.kth.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Daniel Fagerstrom wrote:
> I suggested that we should ditch our environment abstraction and replace 
> it with the javax.servlet.http set of interfaces, as one step in 
> simplifying Cocoon in 
> http://marc.theaimsgroup.com/?t=113432388200001&r=1&w=2.
> 
> The result of the discussion was that there are some "extras" in our 
> interfaces compared to the http servlet interfaces that are needed in 
> the sitemap, so we would get back incompatibility and maybe other 
> problems and it might be much work to accomplish.
> 
> Now I would instead suggest that our environment interfaces just extends 
> the corresponding Servlet 2.3 (or 2.4) interfaces, Request extends 
> HttpServletRequest etc. This should not create any problems with the 
> current code base at all AFAICS, and would make it easier to make Cocoon 
> cooperate with other systems.
> 
> Calling Cocoon from a Servlet environment is currently not a problem as 
> we have wrappers, but it gets inconvenient to call servlets from  within 
> Cocoon. And the block architecture is Servlet based for making 
> integration and development of new controllers easier and the result 
> more reusable. As the block protocol requires the sitemap to call back 
> the block architecture it would be an advantage if we used the servlet 
> set of interfaces.
> 
> Also for being able to use the CLI with blocks it need to be able to 
> call the block architecture, and here it would also be an advantage if 
> our environment interfaces extended the servlet ones.
> 
> I'd like to implement the above change ASAP, WDYT?
> 
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area and remove the whole environment abstraction completly and
make Cocoon a web framework. Period.

Now, we have currently two other environments: cli and portlets. A
portlet is a web application, so there won't be any problem. And for
the CLI we can come up with some kind of HttpClient that internally
starts Jetty etc.

This would simplify Cocoon even more - and has some other advantages as
well. For example if you're using third party frameworks like spring or
hivemind, they are using servlet context listeners. These are only
available/working in a web environment. So as soon as you are using
something like that, other environmnents would not work. There are other
similar examples to this. For example the portal has extra code that
checks if the portal is used in a servlet environment or not to avoid
startup problems.

And we could use a context listener for setting up Cocoon as well. Which
would make Cocoon easy usable within other frameworks - it's the least
intrusive way. So imagine a struts web app, which is calling Cocoon (and
Cocoon has been set up by the context listener and is available through
the context - similar to what Spring et.all. do).

So, let's simplify Cocoon and remove this extra abstraction completly.

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