cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Hunsberger <>
Subject Re: [proposal] move cforms in core
Date Wed, 23 Feb 2005 15:01:30 GMT
On Wed, 23 Feb 2005 14:54:12 +0000, Upayavira <> wrote:
> Peter Hunsberger wrote:
> > On Wed, 23 Feb 2005 12:05:21 +0100, Stefano Mazzocchi
> > <> wrote:
> >
> >>Ralph Goers wrote:
> >>
> >>>Stefano Mazzocchi wrote:


> >>>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.

+1 Sounds good to me.  

I'd almost want three distributions: "minimal" (no blocks at all),
"default" (or core) and "complete". I'm one of those people that when
I install a piece of software almost always ends up selecting the
"custom" installation option so I can pick and choose what I want
instead of using someone else's preconceived notion of what I want... 
However, in this case, if it's easy to remove blocks I don't see any
real issue.

Peter Hunsberger

View raw message