Ralph Goers wrote:
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.
A block can contain code. It is just (at least in the first step) not allowed to expose components. So if the portlet components need to be accessible from other parts of the system you need both a bundle and a block. But if the components only are needed internally and the portlet can expose all its functionality as pipeline functionality, it is enough with a block.
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.
Seem reasonable.
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?
See above. The block can import and configure components as much as it like.
As I have described in previous discussions, one way to make block extensible and configurable is by using polymorphic sitemap rules. The block, e.g. a portlet, contains configurations and default content that are used through polymorphic sitemap rules. Then a user can extend the original block and overide the sitemap rules that are needed for the application.
We could also let extending blocks get access to the component manager and classloader from the extended block whithout introducing to much complexity. Parent - child classloader dependencies is still easy enough to manage. The problem comes when the blocks start to have mutual depdencies on the Java level.
My only concern here is simply how many moving parts it will take to construct a portal.
If that becomes a problem we must of course solve that.
The main point is that Pier allready has a working system that solves important parts of the "bundle" aspect. According to what he have writen, it is used at VNU and solves a number of our current problems in Cocoon.
And I feel rather confident in start building the blocks part as soon as I find some time for it. We use some simple block like mechanism in our internal webapps, and we have very good experience in. So if we start with those aspects we might have something much more concrete to discuss about in a close future. If that is enough, that is fine, if not we do something about it.
/Daniel
