Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 46300 invoked from network); 16 Oct 2004 17:07:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 16 Oct 2004 17:07:59 -0000 Received: (qmail 83339 invoked by uid 500); 16 Oct 2004 17:07:55 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 83111 invoked by uid 500); 16 Oct 2004 17:07:53 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 83088 invoked by uid 99); 16 Oct 2004 17:07:53 -0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [66.51.199.81] (HELO mail5.dslextreme.com) (66.51.199.81) by apache.org (qpsmtpd/0.28) with SMTP; Sat, 16 Oct 2004 10:07:52 -0700 Received: (qmail 30894 invoked from network); 16 Oct 2004 17:07:50 -0000 Received: from unknown (HELO [192.168.10.10]) (66.51.196.164) by 192.168.8.93 with SMTP; Sat, 16 Oct 2004 17:07:50 +0000 Message-ID: <41715565.8070309@dslextreme.com> Date: Sat, 16 Oct 2004 10:07:49 -0700 From: Ralph Goers User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Some notes about the "Real Blocks" issue Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I must admit, I have issues with this whole discussion. I understand that there are problems with the Avalon community and that the current code base is making implementing real blocks difficult. But I have also used Spring and have issues with that. To summarize: 1. Figuring out what is going on in cocoon.xconf and cocoon.roles is pretty straightforward. Providing enhancements that fulfill the same contracts is easy. In my use of Spring I have not seen the same thing. I just see a bunch of classes being created and set methods called on some of them. 2. I have recently been digging into the Portal block. IMO, Carsten has done a masterful job of leveraging the best of Avalon, Cocoon and Castor. Frankly, I'm just not sure how this could work as well in an environment built on dependency injection. The documentation on the portal is pretty thin. However, because it adhers to contracts it is pretty easy to match up the configuration with the interfaces and then look at what individual classes are doing. I wonder if this would be true with a container such as Spring. In short, the fact that Cocoon is just a bunch of parts that get configured is one of Cocoon's major strengths. However, the current configuration is pretty easy to understand and modify. If the replacement container makes the configuration more complex and less understandable that will really hurt the acceptance of the product.