Reinhard Poetz wrote:
Ralph Goers 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.
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?
OK. Look at the cron block. Then look at conf/cron.xconf. Notice the trigger definitions as well as the two configured CronJobs. These are clearly illustrations on how the cron block can be used, not the actual implementation. To be usable, cron.xconf must be modified by the customer and then redeployed, along with whatever classes are required to run jobs.
In the databases block, datasources.xconf contains a single datasource definition using hsqldb and a hardcoded userid and password. Presumably, to be usable in a real application this would need to be changed.
In the portal there are a number of xconf files. portal.xconf contains definitions every portal needs - although it can be modified to change behaviors. portal.samplesxconf contains definitions needed to create the sample portal. Any portal needs an equivalent to this.
These are only some of the ones I've looked at, but it is clear that, at least as things are now, in many cases a block is not just an isolated component that is built and delivered by us and is not modified by users of Cocoon. It sure would be nice if it was.
Ralph
