[Zope-dev] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.

[Hanno Schlichting]

On Sun, Dec 27, 2009 at 5:43 PM, yuppie <y.2009 at wcm-solutions.de> wrote:
> Tres Seaver wrote:
>> Hanno Schlichting wrote:
> +1 for shipping Zope 2.12.3 with five.formlib
>
> -1 for adding new deprecation warnings in a bugfix release

Ok. So I'll backport five.formlib to the 2.12 branch leaving BBB
imports, have 2.13 issue deprecation warnings pointing to removal in
2.14. Unless Andreas prefers a different approach :)

> Why not following the normal procedure? At some point in the past we
> decided to add formlib support to Zope 2. That's a commitment. We should
> not drop features just like that.

I think five.formlib is better served by being a separate distribution
that can evolve on its own, much like we do it with
five.localsitemanager. I don't understand this as dropping the
support, but as shifting the maintenance to a different group. Both
CMF and Plone use formlib today and have both come up with additions
and new features for it. I want those to go into five.formlib. Having
the code in Zope2 seems to prevented people from doing so.

On the other side many people in the Plone community have started
using z3c.form instead of formlib and it looks like all of Plone will
shift to that. Once that happens I don't want to have formlib to still
be there as a dependency of Zope2 for all eternity.

On the more general note of Five:

When it comes to most of the Five code, there has only been a decision
to include and transition to the Zope 3 app server as a whole at some
point. We know this story hasn't played out. Now I'd like to look at
each zope.* package in its own right and see if it and its five
integration code is warranted to be part of Zope2.

Certainly interfaces, the general CA, zope.configuration, zope.event,
zope.tal, zope.i18n, parts of publishing and traversal have all been
integrated into Zope2 and are used inside the Zope2 code. The same
applies to browser views and pages. But when it comes to formlib,
testbrowser, viewlets/contentproviders, resources, menus and the
default skin via @@standard_macros the situation is all much less
clear.

>From my point of view most of the original UI building blocks of Zope
3 have failed to catch on. More modern systems like repoze.bfg prefer
a much simpler model using ZPT macros or trying to mirror the CMF
skins model. In the Plone world we adopted the CA to build and
customize our UI and it has been a massive failure. I think the
fundamental problem of these technologies is, that they have been
built by developers for developers. We made it incredible hard for
non-developers to do anything meaningful with our UI.

So I think it's time to look at the stuff in Five and ask ourselves
what of it are actually good libraries and concepts. And want of that
stuff we want to keep promoting. And even if want to keep it, I think
we should split up Zope2 into multiple distributions - we just need to
be more careful with it, than the Zope 3 egg explosion.

Hanno