[Zope-CMF] Re: [dev] CMF 1.5 roadmap?

[Florent Guillaume]

Chris wrote:
> I'd like to see Archetypes in there.  The reason I'd like to see it in
> there is because:

-1 from me.

I don't think Archetypes should be in the CMF distribution. I'm opposed
to it on technical and political grounds which I'll detail below.

> a) It works very well and is quite stable, very well-written,
> well-maintained, just generally a good piece of software all-around.
> b) It already works with plain CMF.  You just need to plug it in to the
> repository and maybe tweak a couple of things like stylesheets.

That's the case for lots of other packages, in itself it doesn't warrant
inclusion into CMF.

> c) The authors (Ben Saller and crew) seem to be OK with it going in to
> the core
> d) I'd like to see people rally around CMF rather than balkanizing into
> smaller groups.

Balkanizing is a very strong word. It implies many groups, which is
incorrect, and enemity, which is incorrect also.

I don't think that's the state of the game at all. Speaking just about
Plone and CPS, these are two communities having common goals and working
from a common codebase (CMF) and extending it in the direction that's
best for each. That's hardly balkanization.

> It'd be good to take stock of work that other folks
> have done and allow folks to share their respective burdens by
> consolidating.  The Zope community is still too small for balkanization
> to work in the long run IMHO.
>
> I'm not sure if any of these reasons are compelling, really, and I can
> understand why it might be more advantageous to leave Archetypes out of
> the mix politically and practically.  That said, I think there's an
> opportunity for consolidation here without much pain, and I think
> Archetypes is tremendously useful and takes an substantial amount of
> pain out of writing CMF applications.

Technically, as others have pointed out, I think Archetypes is too big a
piece of code to add to CMF. It adds a whole new level of framework,
which frankly I don't see as the only reasonable way to do things. Other
ways of thinking about schemas and widgets are possible and also valid,
and it'd be too much to choose one and add all its bagage to CMF.

I also have paradigmal (if that's a word) problems about including
Archetypes, because I think having things defined at the class level
removes one level of indirection in defining things TTW which is very
useful and, I think, one of the strong points of CMF with its portal
types. I won't go into details here as it's another discussion entirely.

Finally the political problems for us using CPS is also quite important,
because even though we recognize that Plone has a bigger userbase and
bigger developer community, it doesn't mean it automatically needs to be
implicitely supported by Zope Corp by being partially included in CMF.

Also I don't see what Archetypes would gain by being included in CMF
appart from the political statement. There is already a good CVS base,
mailing-lists, IRC channels, etc. It can evolve at its own pace and the
one that Plone needs it to have. Why tie CMF to it ?


What I'd really like, and others have already mentionned it, is that
many of the smaller fundamental pieces that Archetypes uses be added to
CMF, because they are very useful in general:

 - PortalTransforms, which CPS already uses,

 - the UID tool, which has been lacking for quite a while and which CPS
   would be happy to use too,

 - the references tool,

 - something that can be used to decide what a sequence of screens used
   for edition should be; I don't know if that's the entire scope of
   CMFFormController or FormTool, but this basic function would be
   useful for CPS too.

I think this work of piecewise integration is necessary in any case.


Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 79 87  http://nuxeo.com  mailto:fg at nuxeo.com