Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 10287 invoked from network); 26 Oct 2003 22:51:25 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 26 Oct 2003 22:51:25 -0000 Received: (qmail 86088 invoked by uid 500); 26 Oct 2003 22:51:08 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 86072 invoked by uid 500); 26 Oct 2003 22:51:08 -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 85973 invoked from network); 26 Oct 2003 22:51:07 -0000 Received: from unknown (HELO linux.local) (80.116.68.72) by daedalus.apache.org with SMTP; 26 Oct 2003 22:51:07 -0000 Received: from apache.org (localhost [127.0.0.1]) by linux.local (Postfix) with ESMTP id 3A4C584D40 for ; Sun, 26 Oct 2003 23:51:09 +0100 (CET) Message-ID: <3F9C4FDC.50805@apache.org> Date: Sun, 26 Oct 2003 23:51:08 +0100 From: Gianugo Rabellino User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Sitemap inheritance References: <3F9C02A9.2040904@apache.org> <3F9C4B5B.6070107@leverageweb.com> In-Reply-To: <3F9C4B5B.6070107@leverageweb.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Geoff Howard wrote: > Gianugo Rabellino wrote: > >> In short: blocks should ease a Cocoon developer's life, and block >> assembling should belong to the "programmer" domain. Normal users >> should see only benefits from it. Or am I wrong? > > > > I believe that the benefits from real blocks will be so monumental to > the way people work with Cocoon that every application should be > packaged as a block/group of blocks. Much of the pain of developing > with Cocoon (more than the first little tinkering) goes away. We need > to make sure blocks are not scary to people, but I don't think this is > going to be difficult. I'd propose waiting until we have a first > working draft before further investigating alternatives which replace > blocks. Just to make things clear: I'm not advocating an alternative to replace blocks, I'm a strong fan of it. I just think that blocks should ease development of Cocoon apps, while not becoming the only way of working with Cocoon. In the upcoming future I see lots of blocks being interconnected by traditional sitemap editing as we're used to it now. Sitemap (better: pipeline) inheritance goes in this direction: it's perfectly OK and cool to have it within blocks, but I don't see why it should not be possible even outside them. So I'm not stating anything that goes against blocks: I'm just looking for a way to ease the final user experience with Cocoon. Keeping in mind that the majority of users won't make blocks, but rather just use them. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)