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.
Bundles -------
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 ibiblio.org. 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 ------
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 components.
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?
/Daniel
