Stefano Mazzocchi wrote:
No Avalon container is web/servlet-enabled, that is IMHO the main problem. Some folks report that Sevak can provide web connectivity for Phoenix, but others haven't gotten it to run.
Cocoon needs a way to deploy cocoon-based web application at runtime.
We could do this following the WAR model of the Servlet API, but we aim at more advanced stuff.
So I want Cocoon to be the first web-oriented technology to follow the CoP paradigms.
These 'webapp components' will be called "Cocoon Blocks" (or, in short, COBs). These blocks will be behavioral and polymorphic. Means that I can have a block A (say a webmail webapp) depend on a block B (say a skin implemented using XSLT stylesheets).
So, block A depends on block B implementing some services to skin stuff. This isolates concerns and make webapp composition component-oriented following the good old IoC and SoC patterns.
Downside: currently, no Avalon container allows that kind of flexibility.
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 Blocks
> 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.
Avalon (framework) provides a component model, it does not provide a block model (a block being a collection of components here). Blocks, whether they be Cocoon blocks or Phoenix blocks or whatever else, require a container that internally manages Avalon components.
IMHO there can never be a container, that makes everyone happy, because the container itself is not only a framework, but also an application. 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 :)
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. 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.
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?
And are those features that we give up on application-neutral or application-specific (like Sitemap concerns)?
cheers,
Ulrich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
