cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Another step to blocks: Application container support
Date Fri, 11 Mar 2005 21:44:16 GMT
Carsten Ziegeler wrote:
> At the last GT we agreed that our core should not depend on other
> projects, so we wrote our own container and did not use an existing one.
> We also said that on the application level, a user can use whatever
> container she wants on top of Cocoon.
> It seems that this is a good choice, as we don't redo the work already
> done in the container area in other projects and on the other hand we
> are free to do what we want/need in the core.
> Compared to other solutions out there, our container (avalon based) is
> not state of the art anymore. Other projects like Spring or Hivemind
> have far better features and help in rapid development of component
> based applications. In addition using POJOs is very famous in our days.
> So for real applications you will end up using a different solution,
> being it Spring or Hivemind or whatever - I don't want to drive a
> discussion here about which project of the two is the better one. So I
> just mention both of them and refer to them in the following text just
> by DCC (=different component container).
> Now, I think we should help users in doing this. I'm currently thinking
> about directly supporting DCC on the application level and therefore
> creating support for an "application container" (We can later on
> decide if we support both, or just one of them or a totally different one.)
> With the latest additions to the trunk we nearly have the most important
> features of blocks already implemented - and that without really having
> a block as an object/component. Currently the sitemap is the central
> point for an application: you can include xconfs, define an own
> classpath etc.
> Currently I see the need for two additional features:
> a) "a request listener" - I want to be able to act on each request
> comming into my sitemap; and in addition I would like to do something
> when the request is finished which means *after* the serializer wrote
> the content into the stream. Now, doing something on each request *can*
> be done by using actions or some flow script; but actions can't be run
> after the serializer and it's a lot of overhead to use flow script for
> each and every request.
> We already have a listener, but unfortunately this is tied to the
> processor. So you can only have one listener for every request entering
> Cocoon - but not on a per sitemap level.
> b) Direct support for DCC. Using these frameworks is not that difficult
> inside Cocoon, but I think it could be easier.
> What do you think if e.g. a "getComponent("something")" in flow uses a
> Spring BeanFactory (and if the factory does not have the bean/component
> then the usual Avalon mechanism is used). The same would happen if you
> get a service manager from the Cocoon core.
> We could tie this to a sitemap as well, so you can have different
> configured DCC containers running inside Cocoon - for each
> application you're running inside Cocoon an own one. (Don't know if this
> is possible with DCC, but I guess so). So there are two differences to
> using DCC without explicit Cocoon support: a) the usual Cocoon mechanism
> for components (lookup/getComponent) works as well and b) you can have
> different applications with different DCC configurations. In addition
> they are shielded by own classloaders!
> We could extend this and add some additional glue code that makes core
> Cocoon features (like the Context, settings etc.) available to the DCC.
> With these additions we get kind of a "sitemap controller" (or
> whatever we call it): component configurations (xconf), DCC support,
> class loading, listeners etc. This sitemap controller could become later
> on the "block logic" or the block object/component.
> While a) is easy to implement and does not really have an impact, b) is
> imho the glue to support rapid application development with Cocoon even
> more - just tell Cocoon that you want to use your favorite DCC framework
>  via the sitemap and Cocoon sets up everything for you.
> We could either start adding these additional things into the sitemap
> (like we did with class loading and configurations) or we could think
> about using an additional configuration file that is optional and lies
> in the same directory as a sitemap. This file could be the start for a
> block descriptor. I personally don't care which way we choose as a
> start, although I think adding this to the sitemap is the quicker way.
> So, WDYT?

I have no strong opinions on this as I don't need it, but as far as 
things are back compatible and we don't add additional dependencies to 
the core, I see no problem in letting do what you think it's the best in 
this space.


View raw message