Re: [Zope-dev] SVN: Zope/trunk/ Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Log message for revision 107134: Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
YAY! You rock, Hanno. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks29uUACgkQ+gerLs4ltQ5PxgCfXATXRVia/zjPBdCejJUJqi9s +2UAnRh2weLA/U60QlLhivv+TDLxUsWZ =QuLv -----END PGP SIGNATURE-----
On Sun, Dec 27, 2009 at 6:55 AM, Tres Seaver <tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
Log message for revision 107134: Moved zope.formlib / zope.app.form integration into a separate package called five.formlib.
YAY! You rock, Hanno.
Thanks, we all did our part to get Zope2 "zope.app"-free :) One question about the separation remains, though. When and how can we drop the five.formlib dependency from Zope2 itself? The deprecation warnings don't mention a release or date when they'll be gone. But in order to get Zope2 really app-free we need to drop the direct five.formlib dependency at some point, or we still pull things in via transitive dependencies. Is deprecating in 2.13 and removal in 2.14 ok? Or does anyone have a different preference? Is it ok to backport this to 2.12? Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Sun, Dec 27, 2009 at 6:55 AM, Tres Seaver <tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
Log message for revision 107134: Moved zope.formlib / zope.app.form integration into a separate package called five.formlib. YAY! You rock, Hanno.
Thanks, we all did our part to get Zope2 "zope.app"-free :)
One question about the separation remains, though. When and how can we drop the five.formlib dependency from Zope2 itself? The deprecation warnings don't mention a release or date when they'll be gone.
But in order to get Zope2 really app-free we need to drop the direct five.formlib dependency at some point, or we still pull things in via transitive dependencies.
Is deprecating in 2.13 and removal in 2.14 ok? Or does anyone have a different preference? Is it ok to backport this to 2.12?
+1 to dropping it in Zope 2.13: folks who are using it will just need to add one egg to their buildouts (or their install_requires) and adjust imports, right? Anyway, in the interests of getting to a clean "runs on ZTK" label sticker on the box, "onward and upward." Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks3atEACgkQ+gerLs4ltQ6uyACg16sfVuN3MMwnQoafBjqzUJE/ 41YAnAoCD8TBLi8LFd7MQCZ7B8IO+H0q =GN1X -----END PGP SIGNATURE-----
On Sun, Dec 27, 2009 at 3:10 PM, Tres Seaver <tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
Is deprecating in 2.13 and removal in 2.14 ok? Or does anyone have a different preference? Is it ok to backport this to 2.12?
+1 to dropping it in Zope 2.13: folks who are using it will just need to add one egg to their buildouts (or their install_requires) and adjust imports, right? Anyway, in the interests of getting to a clean "runs on ZTK" label sticker on the box, "onward and upward."
Ok. I'm in favor of that. I'd only do it if we backport this stuff to 2.12, so you get at least one release with deprecation warnings. I'd be willing to adjust CMF to use all the new imports ;) I think it also might be a good idea to move some of the formlib helper classes from CMF into the five.formlib package. There's some helper classes for property conversion and such, which should be more low-level. Andreas, any objections to this backport? Hanno
Hi! Tres Seaver wrote:
Hanno Schlichting wrote:
But in order to get Zope2 really app-free we need to drop the direct five.formlib dependency at some point, or we still pull things in via transitive dependencies.
Is deprecating in 2.13 and removal in 2.14 ok?
+1 Since it doesn't make sense to mark five.formlib and zope.app.* as deprecated, it would be helpful to announce that ZTK and Zope 2 maintainers will no longer support these packages after Zope 2.12.3.
Or does anyone have a different preference? Is it ok to backport this to 2.12?
+1 for shipping Zope 2.12.3 with five.formlib -1 for adding new deprecation warnings in a bugfix release
+1 to dropping it in Zope 2.13: folks who are using it will just need to add one egg to their buildouts (or their install_requires) and adjust imports, right? Anyway, in the interests of getting to a clean "runs on ZTK" label sticker on the box, "onward and upward."
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. Zope 2.13 can still have the "runs on ZTK" label if it ships with additional packages. Cheers, Yuppie
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
Hi! Hanno Schlichting wrote:
On Sun, Dec 27, 2009 at 5:43 PM, yuppie <y.2009@wcm-solutions.de> wrote:
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.
Exactly. And I expect CMF will also switch to z3c.form.
Once that happens I don't want to have formlib to still be there as a dependency of Zope2 for all eternity.
Agreed. I did just argue against the fast removal Tres proposed. But five.formlib will only evolve for a short period. Soon it will become a pure legacy package. Nothing we want to recommend for new projects. And in the long run five.formlib and its non-ZTK dependencies will become unmaintained. Cheers, Yuppie
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 yuppie wrote:
Hi!
Hanno Schlichting wrote:
On Sun, Dec 27, 2009 at 5:43 PM, yuppie <y.2009@wcm-solutions.de> wrote:
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.
Exactly. And I expect CMF will also switch to z3c.form.
Once that happens I don't want to have formlib to still be there as a dependency of Zope2 for all eternity.
Agreed. I did just argue against the fast removal Tres proposed.
But five.formlib will only evolve for a short period. Soon it will become a pure legacy package. Nothing we want to recommend for new projects. And in the long run five.formlib and its non-ZTK dependencies will become unmaintained.
That is why I want to get it out of the tree *before* 2.13: anybody who needs to use Zope2 but can't add an extra five.formlib egg should just stay on 2.12 until they can. Deprecations are not a cure for this: folks will just defer the pain until the release cycle where things actually disappear, and meanwhile the "core" maintenance is harder. Splitting less-maintained code out into a searate distribution allows for the "conservative" crew to keep using it, while not taxing the mainstream (and the core developers) to support them. Given that 2.13 is unlikely to be out before Q3 of 2010, how hard is it going to be for folks to catch up, anyway? Plone 4 will ship on top of 2.12, Plone 5 is already a more radical break, and can easily accomodate the split (or abandon formlib, whichever). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks361cACgkQ+gerLs4ltQ5nbwCfZbcenLP8RmBbhUj9X20oMnxe mA0An0mbrN4FNaCrwIK2WzHFXSpg+/T+ =l0dx -----END PGP SIGNATURE-----
Hanno Schlichting wrote:
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.
I'm not sure I'd agree completely with what you're saying. I think *viewlets* have been a problem in the way that they are used in Plone, i.e. as a general page composition mechanism. In hindsight, I wish we'd had maybe half a dozen viewlet providers at most, used only for things like status messages or extra <head /> content being plugged in by third party systems. On balance, I think browser views have provided a huge benefit over what people were doing before, in that they provide a sane place to put "display logic". I know the separate ZCML registration step has been a hampering for some, but with grokcore.view/five.grok that's become easier. Customisation is still not as esay as it is with portal_skins, unless you're using z3c.jbot, in which case it's arguably easier. I don't necessarily disagree with your diagnosis: too many of these things were written by developers for developers. It seems sometimes like the goal of a "pluggable" UI, where packages plug themselves into an overall structure, has been allowed to overshadow the goal of a "customiseable" UI, where integrators can easily customise the UI to their needs. However, on balance, I think the move to Zope 3-style views, at least, has been positive. I'm in the intersting position right now of teaching "new" techniques to a team that has been on Plone 2.5 and done everything TTW for a long time. Some "new" things they reject as too obscure. But there are more "new" techniques that they see as a blessing, recognising many of the problems they had in the past. Careful with the bathwater again... :-) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
participants (4)
-
Hanno Schlichting -
Martin Aspeli -
Tres Seaver -
yuppie