On Sun, Dec 27, 2009 at 5:43 PM, yuppie <y.2009@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