Geoff, I didn't mean to hurt anybody with my statement, but I find it quite difficult to accept your answer. Here's why. I've been using Cocoon in a corporate environment (msdw, london) since it's 1.8 release, and back then we successfully implemented a couple of applications based on frameworks such as cocoon, struts, castor, etc.
I do realize (more than I should have to ... ;-)) that this is an open source project and that documentation will never be complete. I remember problems with xsp logicsheets back in the 1.8.1 days that one could resolve by looking at the logicsheets themselves. But the crucial point here is that with those problems, one was looking at something very specific. A (complete) list of blocks in the 2.1.1 release imho is something very basic. Let's imagine I'd still be working for msdw (which I am not). I've read about the new features of Cocoon 2.1, and I am about to make the case (towards management) to invest some time and money to investigate an upgrade to e.g. 2.1.1. Please bear in mind that with big corporations like these, investigating software in a case where an older release works is (generally) considered to be 'unproductive' time. I never shared these thoughts, but this is about a working environment and its policies and its pressure. I just downloaded 2.1.1 for the first time, as I am preparing myself for the odd lecture in a couple of weeks. Starting at the installation documentation, I am very pleased to find some basic information about blocks and how this can be used to configure and deploy a custom-built version of Cocoon. But that's exactly where the problem for me (and most of big commercial companies that these days actively consider to use Cocoon in the future) starts. There is a new mechanism that for the first time allows to customize the way that Cocoon is deployed, but the information required to make installation decisions in a well-informed way is missing. I know that CocoonWiki has some of this information, but that's not the point. The point is that we are talking about the installation of Cocoon, not some hidden or not so obvious feature somewhere in a block or even the scratchpad. I agree that looking at samples is a very good way to address problems/questions when trying to find your way around with special problems, block usage, etc., but nor for such a basic task as installation and its customization. Please do not get me wrong. I really dig Cocoon, I used it wherever possible in corporate environments despite varying pressure re: its complexity, lack of documentation (back then Cognacs didn't exist), etc. But wanting to build and install Cocoon, and not being able to find the relevant information re: blocks is a bit hard. One more thing: I'd love to contribute, and I will definitely do so. But I can only contribute in areas where I am literate. And I do not have any intentions to do so in areas that are not of my interest (e.g. php, etc.) or where I lack the knowledge. I don't think it would be very hard to develop a policy where a block contributor/maintainer could make a block available only if she provides enough information to facilitate the creation of such a complete list. I think it would be in their interest, and in everybody's interest who loves Cocoon for what is it and strives to be. Werner PS Speaking of which, can somebody enlighten me as to why the CastorTransformer still is part of the scratchpad block. And what would it take to move it to its separate block ? On Thu, 25 Sep 2003 15:27:51 -0400, Geoff Howard wrote: >Werner Guttmann wrote: >> And where could one possibly maybe find a complete description ? >> >> Werner >> > >Obviously its still a work in progress - if such a document existed you >would have found it by now or we would have sent you to it. I'd suggest >reviewing the samples for each block and if you are so inclined, add >some better description to the wiki page so that others can benefit from >your work. > >Geoff > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
