Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <421C9914.5020405@upaya.co.uk>
Date: Wed, 23 Feb 2005 14:54:12 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041124)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [proposal] move cforms in core
References: <421B58FB.1030607@apache.org>
 <421B66BA.4010808@dslextreme.com>	 <421C6371.8010107@apache.org>
 <cc159a4a05022306418f6267b@mail.gmail.com>
In-Reply-To: <cc159a4a05022306418f6267b@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Hunsberger wrote:
> On Wed, 23 Feb 2005 12:05:21 +0100, Stefano Mazzocchi
> <stefano@apache.org> wrote:
> 
>>Ralph Goers wrote:
>>
>>>Stefano Mazzocchi wrote:
>>>
>>>
>>>>The more I go around talking about what cocoon is, the more I think
>>>>that cforms should not be a block. This also requires the 'template'
>>>>system to reside in the core.
>>>>
>>>>So, here is my proposal:
>>>>
>>>> 1) move cforms in core
>>>
>>>I'd like to hear why you think cforms should not be a block.
>>
>>Because having it as a block makes it really hard to answer the
>>question: what is cocoon and what does it provide me.
>>
>>I think it's useful to have a list of things that cocoon comes with and
>>a form handling framework is something that *must* be part of the core.
> 
> 
> Please no.  We don't need cForms for our work.  Other people may not
> need it either.
> 
> Having it in a block doesn't somehow remove it from Cocoon.  You can
> still tell people that Cocoon has built in forms capabilities and you
> can make it very easy for people to get them.  However, bundling
> cFroms into the core makes the opposite much harder.

And this is why, in association with Reinhard, I have started talking 
about "core blocks". These blocks will be documented within the core 
documentation of Cocoon, not within the blocks themselves. This is 
precisely for the reasons Stefano gives - it will give the impression 
that it is an integral part of Cocoon, not a bolt-on. However, going a 
bit deeper, you'll find that forms is implemented as a block.

I would even go a bit further - once we've got our blocks system fully 
in place, we could have two distributions - core and complete. Core just 
includes the core and the core blocks, and complete contains them all. 
That way, anyone who wants Cocoon, but doesn't want any of these 'core 
blocks' can quite easily remove them from their webapp - but they're in 
the distribution by default, always.

That's my thoughts on the subject.

Regards, Upayavira