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
