Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <dev@cocoon.apache.org>
Subject: RE: [RT] Less is More, Finite State Machines and Balkanization
Date: Sat, 12 Jul 2003 22:14:23 +0200
Message-ID: <LKENJPKDAIKAPKHEOCMMEEAJEEAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3F0EF465.2090205@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Stefano Mazzocchi wrote:
>
> We choose one direction for our core and we keep evolving that. No
> polymorphism just because a few people have legacy they want to reuse,
> it's not our problem.
>
> Yeah, the next thing to unify will have to be the form handling. XMLForm
> and JXForm will be shortly unified. Hopefully, Woody will be as well.

I think one of the main tasks for 2.2 will be unifying and consolidating the
code. We have three form handling blocks, several including mechanism, many
template approaches etc.
It's not good to offer users many different ways to do one single thing. But
it's good to have different implementations/designs/ideas to make the single
usable solution. A unified development effort can really increase the
result.
We (s&n and BASF IT Services) for example have seen this with the new
portal framework; it's much better than the single ideas we or BASF IT
Services
allone had (although of course the single ideas where not bad).

>
> Balkanization is the problem. FS is the signal. Community fragementation
> is the danger, expecially when blocks will be there.
Yepp, we should control the creation of new blocks when the time comes.

>
> So, instead of routing around consensus, let's work toward it, that
> means: no abstraction for core parts.
>
> It seems like everybody has an agenda to place their favorite technology
> right in the core of cocoon.
Yes, and that's one of the points I didn't like with flow in the first
beginning,
because it's tight to the core and the core had to be changed in some
places.
Now, if you say flow belongs to the core (and we do this now), then it's ok
to change the core. But it should be avoided to change the core for anything
that doesn't belong to it.

Before someone else mentions it: some of you might have noticed that I
started
Dywel, another project/block for cocoon dealing with (what else?) form
handling,
continuations etc. First, before you get worried about it, it's only an
experiment of building a better way of building web applications with
Cocoon.
Perhaps, I'm on the wrong track and will trash it as soon as I realize it.
Therefore
I will not add it to the Cocoon CVS before I really see the value of it.
The main idea is to add a "framework" on top of Cocoon with all the existing
structure, but without changing anything in Cocoon. I think this is
possible.
For most parts, like e.g. form handling or continuations, I plan to use
the existing things in Cocoon instead of developing another version of an
already existing thing.
But I have to do it as I had the ideas for it more than three years ago when
I left the WebObjects development area and came directly to Cocoon. So, it's
more a personal challenge then anything else.

Carsten