Ulrich Mayring wrote:
No. Cocoon is already completely abstracted from the servlet context. We are not asking for an avalon container to be servlet-aware since Cocoon provides that abstraction.Stefano Mazzocchi wrote:Downside: currently, no Avalon container allows that kind of flexibility.
No Avalon container is web/servlet-enabled, that is IMHO the main problem.
ECM wrapped with some cocoon-specific changes. (no, it's not a modified version of ECM, we just extend some of its classes)Result: Cocoon will *NOT* upgrade to a more modern Avalon container until all the Cocoon Block requirements are met. (we don't want to do the job twice!)
Which Avalon container does Cocoon use right now?
> Detailed description of Cocoon BlocksThis is exactly the point that Stephen and I discussed on cocoon-dev. In fact, a Cocoon Block *extends* an Avalon Block since it provides Cocoon-specific features (like sitemap awareness).
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
Ok, in this document there are some requirements, that are Cocoon-specific, such as Sitemap connectivity. I'm not sure how that could be addressed in an Avalon container or whether it even should.
The idea is that the avalon container is general enough to allow container users (cocoon) to extend it for its needs.
Avalon (framework) provides a component model, it does not provide a block model (a block being a collection of components here).The original Avalon design that Pier, Fede and I wrote included both. You can see fossil traces of the block concept around, expecially in Phoenix. Since many people on this list didn't like the block concept (nor found a serious use for it) it was slowly abandoned.
I'm not asking for Avalon to resurrect the concept, but I do believe there is a need for different granularity of component models and my design outline on cocoon blocks shows that.
But, as I stated previously, nobody forces Cocoon to use Avalon implementations coming out of this community, nor this community to adopt all Cocoon design decisions.
Blocks, whether they be Cocoon blocks or Phoenix blocks or whatever else, require a container that internally manages Avalon components.Yes. that's why we don't want to write our own container since it will be mostly duplication of effort. We would like to work here to allow us to extend the existing containers for cocoon-specific reasons and use SoC on community development to minimize efforts and maintenance costs over time.
IMHO there can never be a container, that makes everyone happy, because the container itself is not only a framework, but also an application.If you are talking about a drop-in-and-forget container, I agree, you can't make everybody happy.
But a container can be designed to be modular and extensible. You can use it as-it-is if you don't need special functionality, or you can add new stuff to it if you do.
I tend to think that any application that wants to provide its own deployment/management/CoP functionality has to write its own specific container. I'd love to be proven wrong, though :)Cocoon will have to write its own container at the end. I agree. But since 80% of the functionality will overlap with other modern avalon containers, I would love to be able to use those and extend them in a future-compatible way, rather than rewrite that 80% functionality and have to maintain it ourselves.
Now, suppose we were to say that our CoP-oriented web application framework does not need a block-concept, it would be sufficient to have a component concept.Fair enough. That will mean that if Cocoon wants to have the notion of blocks, we'll have to implement that part ourselves and reuse the part that the avalon container of choice gives us.
Then we could just use Avalon's existing component concept and would not have to worry about containers. This is not a theoretical idea, there already are application frameworks that use Avalon's component model to build applications following the CoP paradigms. As stated above, what's missing is the Web/Servlet part, but CoP-oriented web application design is possible and has been done with, for example, a combination of Avalon, Phoenix and X:Forge.Oh, I'm not saying that the cocoon block approach is the only way to add CoP concepts to webapp design. Cocoon Blocks were designed to improve on the cocoon operational model.
So, to me the interesting question is: what do we give up if we give up on a block-concept and instead rely only on a component concept?In the original avalon idea:
an application is a collection of blocks
a block is a collection of components
a component is a colletion of services
A collection is one of more of some items.
So far, all of these concepts were implemented using java classes. Cocoon Blocks introduce a new concept of a 'component' (which is a collection of services) that is implemented using an application-specific concept (the sitemap).
In short, a sitemap can be seen as another syntax to describe a component that provides processing services as xml-connected pipelines.
So, if we give up the concept of blocks, we give up the ability to mix, into the same operational unit, components described with different semantics (say, java objects and sitemaps)
This is not a big issue, really and something that can easily be addressed at the application-level.
And are those features that we give up on application-neutral or application-specific (like Sitemap concerns)?If the container doesn't understand the concept of blocks, this is not a big deal and, for sure, we are not asking the avalon general implementation to be sitemap-aware.
What I ask is the ability to extend the container easily with components which are not implemented as java objects but with other, application-specific constructs.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
