cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: Java components in blocks
Date Mon, 18 Apr 2005 06:12:49 GMT
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.


View raw message