Integrating Five code properly into Zope2?
Hi. I'd like to push code and ZCML from Products.Five into the appropriate places in Zope2. For example event.zcml registering events for OFS items, should live in the OFS package. i18n.zcml setting up stuff for the request or the publisher should live in the ZPublisher package, security bridging code for zope.security vs. AccessControl should go into AccessControl, test setup and support code should live in Testing, ... startup code and site.zcml handling should live in the Zope2.Startup package and so on. There's probably some bridging code left in Five which has no real place to go in Zope2. Like formlib wrapping / bridging code - I'd leave this in Five for the time being until we get a clearer picture of what is actually left in there. Given our current deprecation policy, I'd leave indefinite backwards compatibility imports in place and do the same for ZCML files. It would be work targeted at the lucky numbered Zope 2.13 ;-) Do people generally agree with this direction? Hanno P.S. Maybe this would allow one day to remove the Five package again from the main Zope2 distribution, ... maybe :)
Hanno Schlichting wrote:
Hi.
I'd like to push code and ZCML from Products.Five into the appropriate places in Zope2.
For example event.zcml registering events for OFS items, should live in the OFS package. i18n.zcml setting up stuff for the request or the publisher should live in the ZPublisher package, security bridging code for zope.security vs. AccessControl should go into AccessControl, test setup and support code should live in Testing, ... startup code and site.zcml handling should live in the Zope2.Startup package and so on. There's probably some bridging code left in Five which has no real place to go in Zope2. Like formlib wrapping / bridging code - I'd leave this in Five for the time being until we get a clearer picture of what is actually left in there.
Given our current deprecation policy, I'd leave indefinite backwards compatibility imports in place and do the same for ZCML files. It would be work targeted at the lucky numbered Zope 2.13 ;-)
Do people generally agree with this direction?
+1 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 07/26/2009 06:42 PM, Hanno Schlichting wrote:
Hi.
I'd like to push code and ZCML from Products.Five into the appropriate places in Zope2.
For example event.zcml registering events for OFS items, should live in the OFS package. i18n.zcml setting up stuff for the request or the publisher should live in the ZPublisher package, security bridging code for zope.security vs. AccessControl should go into AccessControl, test setup and support code should live in Testing, ... startup code and site.zcml handling should live in the Zope2.Startup package and so on. There's probably some bridging code left in Five which has no real place to go in Zope2. Like formlib wrapping / bridging code - I'd leave this in Five for the time being until we get a clearer picture of what is actually left in there.
Given our current deprecation policy, I'd leave indefinite backwards compatibility imports in place and do the same for ZCML files. It would be work targeted at the lucky numbered Zope 2.13 ;-)
Do people generally agree with this direction?
Sounds good: putting the domain-specific code into the Five package compares to sorting your books by colour. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
2009/7/26 Hanno Schlichting <hanno@hannosch.eu>:
Do people generally agree with this direction?
I have no objections.
P.S. Maybe this would allow one day to remove the Five package again from the main Zope2 distribution, ... maybe :)
Well, simplification is always good, but I predict that Products.Five will go away the day Zope2 becomes a set of BBB packages for ZTK. ;-) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Hi.
I'd like to push code and ZCML from Products.Five into the appropriate places in Zope2.
For example event.zcml registering events for OFS items, should live in the OFS package. i18n.zcml setting up stuff for the request or the publisher should live in the ZPublisher package, security bridging code for zope.security vs. AccessControl should go into AccessControl, test setup and support code should live in Testing, ... startup code and site.zcml handling should live in the Zope2.Startup package and so on. There's probably some bridging code left in Five which has no real place to go in Zope2. Like formlib wrapping / bridging code - I'd leave this in Five for the time being until we get a clearer picture of what is actually left in there.
+1 in general, as long as we don't let any zope.app dependencies leak out while this happens. I would also be +1 to removing the formlib and viewlet integration into separate eggs: I don't think either of them belongs in core Zope2 at all, and anybody who wants the features should be able to pull in the eggs (call them 'five.formlib' and 'five.viewlets', or something).
Given our current deprecation policy, I'd leave indefinite backwards compatibility imports in place and do the same for ZCML files. It would be work targeted at the lucky numbered Zope 2.13 ;-)
Do people generally agree with this direction?
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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKcdvB+gerLs4ltQ4RAgBxAKDPuibqOixBJeq4rqoy0hIA6UOmFwCghNV6 d0q0OcjWROdQqdCG+dJFzCg= =wRG6 -----END PGP SIGNATURE-----
On Thu, Jul 30, 2009 at 7:43 PM, Tres Seaver<tseaver@palladion.com> wrote:
Hanno Schlichting wrote:
I'd like to push code and ZCML from Products.Five into the appropriate places in Zope2.
+1 in general, as long as we don't let any zope.app dependencies leak out while this happens.
Hhm, personally I don't care that much if we "fix and remove" the zope.app dependencies later on from Five or somewhere else inside the Zope2 distribution. But I'll try to keep an eye on that.
I would also be +1 to removing the formlib and viewlet integration into separate eggs: I don't think either of them belongs in core Zope2 at all, and anybody who wants the features should be able to pull in the eggs (call them 'five.formlib' and 'five.viewlets', or something).
I thought about that as well for a while. If more people agree on that, I think this is sensible to do. For both of these leaving indefinite compatibility imports in place that point to the new packages defeats the purpose of loosing the dependencies, though. So how exactly would a deprecation of this code look like? Make the two new five.* distributions available with the current code now, use zope.deprecation to import but warn about the removal in 2.13 and remove the whole code in 2.14? Or can we still stick the deprecation into 2.12 and already remove in 2.13? Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Thu, Jul 30, 2009 at 7:43 PM, Tres Seaver<tseaver@palladion.com> wrote:
I would also be +1 to removing the formlib and viewlet integration into separate eggs: I don't think either of them belongs in core Zope2 at all, and anybody who wants the features should be able to pull in the eggs (call them 'five.formlib' and 'five.viewlets', or something).
I thought about that as well for a while.
If more people agree on that, I think this is sensible to do. For both of these leaving indefinite compatibility imports in place that point to the new packages defeats the purpose of loosing the dependencies, though.
So how exactly would a deprecation of this code look like? Make the two new five.* distributions available with the current code now, use zope.deprecation to import but warn about the removal in 2.13 and remove the whole code in 2.14? Or can we still stick the deprecation into 2.12 and already remove in 2.13?
+1 to the latter, with a prominent note in the changelogs. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKceV9+gerLs4ltQ4RAgVxAJ4m8jiC4eonh2gkRbUojNa0aQFo6wCfVoLY Gh9Iya3A2tKLz5lY9B6+ta0= =hFaq -----END PGP SIGNATURE-----
participants (5)
-
Christian Theune -
Hanno Schlichting -
Lennart Regebro -
Martin Aspeli -
Tres Seaver