cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Java components in blocks
Date Mon, 18 Apr 2005 12:05:47 GMT
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 

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 

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.


View raw message