Reinhard Poetz wrote:
Many of the current blocks, such as the portal, are really just a shell and can't be "deployed" into Cocoon without some sort of implementation. Currently, the sample provides that and so what you end up with is a sample block. Unless we radically rearchitect how these things are configured, there is no way to "ship" a block in a format that doesn't have to be tailored. For example, in the portal there are two xconf files - one that every deployment should have and one for the samples.Ralph Goers wrote:
2. The cob. This would merge the block jar and the sample into an installable or deployable block.
I wouldn't call it sample. It's a Cocoon application that provides pipelines (via sitemap) and flowscripts. We will have to find a better name than sample.
Granted, some blocks may not exhibit this behavior as they simply provide services that other blocks and pipelines can use, but many do much more than that.
could you explain this using concrete examples?
--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}web(log): http://www.poetz.cc --------------------------------------------------------------------
