Daniel Fagerstrom wrote:
Blocks are of course also packaged, distributed and dependency resolved much like the bundles above.
--- o0o ---
So WDYT, does this make sense for your use cases?
Thanks. Yes, this makes a lot more sense. I'm not sure how workable it will be, but it is possible it might be. The only real issue I see is for the person trying to construct a portal. They need:
a. A main sitemap that defines the portal sitemap components, the component-configurations section that defines the name of the portal and its profiles, and the main portal pipeline.
b. additions to cocoon.xconf (presumably through their own xconf) that configures components that are in the portal bundle, or possibly in their own bundle if they choose to implement their own features.
c. the portal definition files (these are obtained via pipelines in the user's main portal sitemap and might be dynamically generated).
The portal definition files define how individual portlets are invoked and rendered. As I stated before, ideally these would be separate blocks. However, since many will contain java code, it sounds like many portlets would have to be a block with a matching bundle. JSR-168 portlets I guess would have to be bundles, if they are packaged for Cocoon, as they don't contain a sitemap of any kind.
So as I understand it, a block would have the sitemap and would require a companion bundle which contained the xconf file if it had any components that need to be configured, or if it needs to configure components provided in another bundle. Is that correct?
My only concern here is simply how many moving parts it will take to construct a portal.
Ralph
