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 Sun, 17 Apr 2005 17:36:56 GMT
Ralph Goers wrote:

> Pier Fumagalli wrote:
>> My vision is quite simple... How many _COMPONENT_ interfaces we need 
>> for Cocoon? Probably 3:
>> "Generator"
>> "Transformer"
>> "Serializer"
>> (well, you might have another 2 or 3 of them but do you see the point?)
> Please take a look at the Portal and then explain how the above works 
> for that.  There are a heck of a lot more components that someone 
> building a portal needs to configure besides these.  Sitemap 
> components are only uses in Cocoon Portlets.  While each Portal 
> request is fired off by the PortalGenerator, it invokes a lot of 
> elements that are configured by whoever puts together the portal.

Don't have time to take any detailed look at the portal ATM, but I give 
my view on the main concepts and then you can see if they seem to help 
your use case.

In the original proposal was the idea that a block exposes both sitemap 
functionality and components. Our current idea is that we, at least 
initially handles the two areas separately. Let us for concretness call 
the sitemap aspect a block and the component aspect a bundle.


A bundle contains one or more components and some meta info. The meta 
info can be about dependecies on components in other bundles it could 
also contain default configurations and possibly other stuff. There 
might be special interface bundles that only contain the apis. A bundle 
would typically be a jar and we would store them in repositories like We could use Maven for downloading them and resolve the 
dependencies and e.g. Pier's kernel for managing them an providing 
classloader shielding.

A large part of our current blocks would be bundles rather than blocks. 
Most of the portal would probably be packaged as a bundle.

Component management is not my main expertise, but I wouldn't be 
supprised if much of what we need in this area already is developed in 
some other projects.


Blocks are at the sitemap level. It is like a small configurable and 
possibly extendable webapp the can be used as part of user webapps. Its 
main communication line with the rest of the application is the block 
protocol, it takes an URI and a request object and returns a response 
object. You can use it internally and/or mount its URI space so that 
Cocoon expose it to the external world. A block can also expose sitemap 

A block can depend on components from bundles but it doesn't expose 
components (at least we hope that it will be enough). A block can 
contain own Java code for internal use.

Block can be full application frameworks like Forrest, Lenya, Linotype 
and possibly a portal application. A WebDAV repository could be packaged 
as a block. A set of webservices could also be packaged as a block. 
Blocks can also be smaller and more specialized things like skins or the 
examples Pier gave. Maybe prtlets could make sense as blocks. A large 
application block probably is put together from a number of small blocks.

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?


View raw message