cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] The environment abstraction, part II
Date Mon, 30 Jan 2006 22:35:05 GMT
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>   
>> Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based 
>> implementation of the servlet API, but having the Cocoon CLI launching 
>> an internal Jetty for this really seems wrong to me. Forrest is already 
>> a large beast, now if you say that generating a site requires to start a 
>> servlet engine, many people with run away for something probably less 
>> powerful but much more light.
>>
>>     
> Then let them run. No, seriously, we can be all to everyone. This is the
> flexibility syndrom in action. From a user pov, where is the difference
> in starting the current cli and starting a cli which internally fires up
> jetty and uses http? It's transparent - but it makes the implementation
> of Cocoon much easier.
>   

Sorry, but I still fail to see how this changes anything. It makes it 
easier to develop with Cocoon as using the standard servlet API rather 
than with a "proprietary clone" eases the learning process and 
facilitates the integration with 3rd-party libraries. But does it change 
something for the internal code? I fail to see how.

>> Now Cocoon is much more than a web framework, as we discussed in the 
>> "necessary mutation" thread:
>> - a servlet
>> - a component container
>> - a controller
>> - a pipeline engine
>> - many blocks built on top of one of the above.
>>     
> So, if someone asks you what Cocoon is, you say the above? Lock at the
> first sentence at cocoon.apache.org: "Apache Cocoon is a web development
> framework built around the concepts of separation of concerns and
> component-based web development."
>   

Then the next question is "how is it different from 
Struts/Spring/Webwork?", and the answer is the list above.

> Now, you could argue that the docs are out-dated, but I think the point
> is that Cocoon has always been marketed as a web framework - and that is
> the area we should focus on. Everything else, being it cli or portlet
> env or whatever can be built somehow "on top" of the web framework.
>
>   
>> This uses the servlet API, as calling Cocoon from Struts is done using 
>> the request dispatcher:
>>   request.getRequestDispatcher("/path/to/cocoon").forward(request, response)
>>     
>
> Yupp.
>
> Now, if I'm the only one thinking that removing the whole env
> abstraction makes sense, I'll shut up for now.
>   

I never said it doesn't make sense, rather the contrary. But there's a 
difference IMO between "let's use the standard servlet API" and "let's 
fire up a servlet engine to process a simple XML pipeline".

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message