On Mon, 12 Aug 2002, Leigh Dodds wrote: > > This was one of the core issues Cocoon Blocks should solve in the end.> > > Giacomo > > As an irregular member of this list, I keep seeing 'Blocks' being mentioned > (usually as the solution to all kinds of problems! :) > > Can anyone point me to some documentation, list discussion threads, or > even scratchpad stuff that describes/demonstrates what Blocks actually > are?
One major point is that Cocoon scales good from the sitemap point of view (root-sitemap -> sub-sitemap -> ... -> sub-sitemap) but does not on the Component level (one single cocoon.xconf). Everybody which ever tried to integrate a Cocoon application which comes with its own Avalon Components into an already running Cocoon system knows what I am talking about. You need to merge those new Components into the cocoon.xconf file for every new application you'd like to deploy in the same Cocoon system and this can grow into a maintainance nightmare. The other point Cocoon Blocks (COB) will solve is modularisation. Consider the following. 1. There is a COB interface defined about skinning application data of defined XSchemas (navigations, menues, content) by transformations (i.e. XSLT) into something else (i.e. HTML) 2. There is a COB interface defined about accessing mail messages which generates defined XSchemas of mail messages and mail folders from mail stores like IMAP, POP, mboxes or "write your own" 3. There is a COB which offers an WebMail application which depends on - a skinning COB - a mail message accessing COB Now, when someone likes to deploy the WebMailCOB it uses the Cocoon COB management application which asks for a URI to the COB to deploy. As a COB will have meta data inside, the management console will be able to ask for configuration data for the COB and also knows of unresolved dependancies to other COBs. So the deployer of the WebMailCOB will be asked where the dependant skin and access COBs are. Now, the management console could offer implementations for them from a well known site like cob.apache.org (URL will be configurable of course) which have been registered there. Now you can select the Christmas skin COB and the IMAP access COB from the list and configure them to have your WebMail ready and running. And now you will be free to use other skin COBs in terms of minutes or you can write your own to achieve "corporate identity". You have your mails stored in a database and there is no COB for it? Write your own and have them be served by the WebMailCOB. So, Cocoon Blocks will not be "the solution to all kinds of problems" as you might have heared. But it will ease deployment of several "modules" into one single Cocoon system. Stefano and I also used the term "naked Cocoon" which sould be a war file that comes with nothing but what is needed to run the COB management application. This enables users to start with it and deploy COBs to have something running by Cocoon. Hope this and the link Bertrand mentioned in an other mail in this thread will help understand what Cocoon Blocks should solve. Giacomo > I'd like to get this into the Wiki. > > Cheers, > > L. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
