Carsten Ziegeler wrote:
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.
Sorry, what do you mean by "web framework"? Isn't it already one? Or do
you mean "servlet"?
Now, we have currently two other environments: cli and portlets.
There's also BackgroundEnvironment for background jobs.
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.
HttpServletRequest is an interface. So we just have to write a
CliHttpServletRequest that implements that interface, just as we do
today with our own interfaces.
AFAIU, what Daniel is proposing is to add an "extends" statement to our
environment interfaces, which are very close to the standard
javax.servlet ones. Just like we did with Cocoon's SourceResolver
extending Excalibur's SourceResolver.
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).
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
