Ulrich Mayring wrote:
ECM (but I believe very much modified). Also ECM is a "pseudo-container", really.Stefano Mazzocchi wrote: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 BlocksProbably. But the idea is to do a proper extraction of that container framework and do as much work as possible within the avalon scope. Peeps are talking of building "profiles" on top of such a framework to handle more specific needs, with easy tweaking of those profiles for your application-specific needs. SoC, really.
> 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 :)
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?are you referring to cocoon or in general? In general application decomposition, we often find logical partitions of the application into components, and then logical partition of those components into subcomponents, up to a level where a subsubsubcomponent becomes to small as to warrant the component management overhead.
The phoenix block model (now mostly deprecated) was sort of like
component-->block
subcomponent-->component
for the above paragraph. Not clear to me yet what the cocoon block model is. The trick is to find a way to allow arbitrary partitioning without making the supporting code too complex. avalon-sandbox/assembly is work in process which (among other things) aims to do that (IIUC).
And are those features that we give up on application-neutral or application-specific (like Sitemap concerns)?arbitrary partitioning is an application-neutral concern. I'm guessing a cocoon block model would be application-specific, with a large part addressable by application-neutral stuff. We need to figure out how avalon can provide the application-neutral stuff, and also make it easy for cocoon to put the application-specific stuff on top of that.
my take on it so far, cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
