CatalogPathAwareness and zope.lifecycle
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Zope Developers, I've asked about this on the zope@ list, without getting any replies. Talking about it in #zope, I decided that maybe I will have to ask here from another point of view. As I was testing moving a big, old application to Zope 2.13, I was greeted with the following error: (...) from Products.ZCatalog.CatalogPathAwareness import CatalogPathAware ImportError: cannot import name CatalogPathAware Looking at the code informs me that CatalogPathAwareness is deprecated. I since noticed that apart from the depreciation, also the "emtpy" class CatalogPathAware(CatalogAware) has been removed from CatalogPathAwareness.py. The depreciation message points to zope.lifecycleevent. Looking at http://pypi.python.org/pypi/zope.lifecycleevent I see some examples about calling those notify() events, but nothing that would tell me how to replace CatalogPathAware with this stuff. Googling for [CatalogPathAware zope.lifecycleevent] does not give me anything besides some SVN commit messages. So, anybody have some examples of doing this, please? Specifically an example for replacing CatalogPathAware with zope.lifecycleevent. Since this is what the depreciation message talks about, it's been done many times over and should be well documented, right? I also hope that developers are aware that this change involves changing the base classes that classes in production systems out there are based on. I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this? (Personally I don't know those benefits, but I'm open to learn. I'm also open to help if there is any work involved, I'm planning to give back more to the zope community in the near future.) Thank you very much, Regards, Sascha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iD8DBQFNqBeEpYOq9ODq/IoRAr8UAKCmziFbjoJ/rD+jOqycMnzyCjrPngCfQFoP UOqcNboJ0XMuX3z9sBM6z2o= =3aWj -----END PGP SIGNATURE-----
On Fri, Apr 15, 2011 at 12:05 PM, Sascha Welter <zopelist@betabug.ch> wrote:
Looking at http://pypi.python.org/pypi/zope.lifecycleevent I see some examples about calling those notify() events, but nothing that would tell me how to replace CatalogPathAware with this stuff. Googling for [CatalogPathAware zope.lifecycleevent] does not give me anything besides some SVN commit messages.
So, anybody have some examples of doing this, please?
I don't think there's any examples. Documentation for developing with current Zope 2 is virtually non-existant.
Specifically an example for replacing CatalogPathAware with zope.lifecycleevent. Since this is what the depreciation message talks about, it's been done many times over and should be well documented, right?
The last piece of documentation I know of is http://codespeak.net/z3/five/event.html. It's from several years back now and was written when object events where first introduced. The general principle should still be the same, even if the details of import locations have changed.
I also hope that developers are aware that this change involves changing the base classes that classes in production systems out there are based on.
Changing base classes isn't any problem. The only thing that is persisted is the actual class of an instance. The base classes are taken from the current code base, so you can change them to whatever you like without any content migration.
I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this?
The particular code was unused for several years, using manage_* methods is deprecated since Zope 2.8 or 2.9. If you really need this code, just copy it from an old release into your own codebase. Developing with Zope 2 is probably a frustrating experience, but that shouldn't come as a surprise to anyone. The project is dead for several years now and is only kept left alive while Plone is migrating away from it or some long time developers are still using it. It's a large piece of legacy code that has no future - certainly not for new users or developers not already familiar with it. Hanno
On Friday 15 April 2011, Hanno Schlichting wrote:
I don't think there's any examples. Documentation for developing with current Zope 2 is virtually non-existant.
How are people expected to upgrade to new code that replaces the old functionality if there is no documentation for it? What is the justification for removing the old code if there is no real viable upgrade path? Is the old code causing problems?
I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this?
The particular code was unused for several years, using manage_* methods is deprecated since Zope 2.8 or 2.9.
It may have been marked as deprecated for a long time but no actual docs on what to switch to or how to do it instead so that is not really an upgrade path.
If you really need this code, just copy it from an old release into your own codebase.
Developing with Zope 2 is probably a frustrating experience, but that shouldn't come as a surprise to anyone. The project is dead for several years now and is only kept left alive while Plone is migrating away from it or some long time developers are still using it. It's a large piece of legacy code that has no future - certainly not for new users or developers not already familiar with it.
Zope 2.x is only recently been a frustrating experience with features being removed or changed. However even with all of that zope is pretty much one the most reliable and flexible system I can think of. Zope 2.x is still very easy to plug things into and acquisition and traversal are massively powerful. There still don't seem to be any other frameworks that actually take security remotely seriously. So what is the future of zope 2.x? Is any feature that plone does not use to be removed with no documentation until plone no longer needs zope 2.x and then zope 2.x will just be discarded? What about developers who build on zope 2.x and use it very successfully, what should they switch to? Zope 2.13 represented a pretty major upgrade for zope users. Threaded zeo was a huge improvement. I have done a lot of testing recently against relstorage running postgres and memcached vs 2.13 zeo and even under 1000 concurrent connections zeo was faster, more reliable and used less memory. It just seems that there is a real effort to make zope 2.x hostile for people to continue to use. Like we are not wanted and should just move to something else. Zope 2.x is still an amazing product and with some work I believe it could be a major player again since it can still do many extremely useful things that other frameworks can not even approach. If someone did migrate to plone will that be a stable development target with documentation on how to handle upgrades when features are deprecated? Will plone keep the security system of zope 2.x or something like it? Is plone open to changes to speed up usage of the system?
On Sat, Apr 16, 2011 at 3:36 AM, William Heymann <kosh@aesaeion.com> wrote:
What about developers who build on zope 2.x and use it very successfully, what should they switch to?
My personal recommendation would be to either use Django or Pyramid. If you want to stay even closer to Zope, Grok seems to be the natural choice. Do yourself a favor and switch to a project that actually has a community around it. Zope 2 has been dead for years and it won't come back to live. Hanno
(Fri, Apr 15, 2011 at 02:39:26PM +0200) Hanno Schlichting wrote/schrieb/egrapse:
I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this?
The particular code was unused for several years,
Sigh. Sorry Hanno, but just *sigh*. "Unused"? Unused by whom? There is code out there that uses stuff without you or anybody else typing in the code on a keyboard. How can you claim it's unused? Do you make audits on what pieces of code people use in their Zope projects? People want to be able to move an existing Zope app to a new server and a new Zope install there without having to sell the customer onto 15 hours of maintenance coding to fix 100 things that break. Not every project is a new project.
using manage_* methods is deprecated since Zope 2.8 or 2.9.
You are wrong. CHANGES.txt in Zope 2.11 does not know anything about manage_* being deprecated. Instead it says: - Turned deprecation warnings for manage_afterAdd, manage_beforeDelete and manage_afterClone methods into discouraged warnings. These methods will not be removed in Zope 2.11, but stay for the foreseeable future. Using events is still highly encouraged. The CHANGES.txt from 2.12 says: "Downgrade the ``manage_* is discouraged. You should use event subscribers instead`` warnings to debug level logging. This particular warning hasn’t motivated anyone to actually change any code." And it will damn sure not motivate anybody, because code that uses that runs just fine (thank you) and nobody sees any need to "fix" it to use something that is undocumented and not tested in that particular setup. That's not how maintenance on a working system works. CHANGES.txt in 2.13 doesn't know anything about manage_* being deprecated or removed any further. If it doesn't break anything, if it doesn't break new code, why depreciate and why remove it? We've had this same game with zLOG and manage_afterAdd before. They're both still here, for good reason.
If you really need this code, just copy it from an old release into your own codebase.
How about you don't delete it and I don't have to add it back? Less work for you, less work for me, less work for everybody.
Developing with Zope 2 is probably a frustrating experience, but that shouldn't come as a surprise to anyone.
It comes as a surprise to me. In fact, I find developing with Zope 2 quite an amusing and entertaining experience. And easy. You must be doing something wrong. I can understand though that Zope is not a system for newbies to start *right now*, OK.
The project is dead for several years now and is only kept left alive while Plone is migrating away from it or some long time developers are still using it. It's a large piece of legacy code that has no future - certainly not for new users or developers not already familiar with it.
Well, I don't know anything about what Plone is or isn't doing. No Plone was ever able to move to a different Zope version without rewriting basically everything, so maybe you think that's normal. It isn't like that for most everybody else though. IMHO the way to treat a "large piece of legacy code" is *not* to break various things inside it because some other idea to do things seemed so much cooler a while back (but which we also abandoned, because we'll get rid of it all anyway). The way to do that properly is to make it as stable an lasting as you can and let it stay alive till it falls over by itself. So if you think it's dead, OK, but there is no reason to actively kill it piece by piece. Regards, Sascha
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/16/2011 11:55 AM, Sascha Welter wrote:
(Fri, Apr 15, 2011 at 02:39:26PM +0200) Hanno Schlichting wrote/schrieb/egrapse:
I assume this kind of thing has been discussed and the decision has been taken on judging backwards compatibility vs. the benefits of doing this?
The particular code was unused for several years,
Sigh. Sorry Hanno, but just *sigh*.
"Unused"? Unused by whom? There is code out there that uses stuff without you or anybody else typing in the code on a keyboard. How can you claim it's unused? Do you make audits on what pieces of code people use in their Zope projects?
People want to be able to move an existing Zope app to a new server and a new Zope install there without having to sell the customer onto 15 hours of maintenance coding to fix 100 things that break. Not every project is a new project.
using manage_* methods is deprecated since Zope 2.8 or 2.9.
You are wrong.
CHANGES.txt in Zope 2.11 does not know anything about manage_* being deprecated. Instead it says:
- Turned deprecation warnings for manage_afterAdd, manage_beforeDelete and manage_afterClone methods into discouraged warnings. These methods will not be removed in Zope 2.11, but stay for the foreseeable future. Using events is still highly encouraged.
The CHANGES.txt from 2.12 says: "Downgrade the ``manage_* is discouraged. You should use event subscribers instead`` warnings to debug level logging. This particular warning hasn’t motivated anyone to actually change any code." And it will damn sure not motivate anybody, because code that uses that runs just fine (thank you) and nobody sees any need to "fix" it to use something that is undocumented and not tested in that particular setup. That's not how maintenance on a working system works.
CHANGES.txt in 2.13 doesn't know anything about manage_* being deprecated or removed any further.
If it doesn't break anything, if it doesn't break new code, why depreciate and why remove it? We've had this same game with zLOG and manage_afterAdd before. They're both still here, for good reason.
If you really need this code, just copy it from an old release into your own codebase.
How about you don't delete it and I don't have to add it back? Less work for you, less work for me, less work for everybody.
Developing with Zope 2 is probably a frustrating experience, but that shouldn't come as a surprise to anyone.
It comes as a surprise to me. In fact, I find developing with Zope 2 quite an amusing and entertaining experience. And easy. You must be doing something wrong.
I can understand though that Zope is not a system for newbies to start *right now*, OK.
The project is dead for several years now and is only kept left alive while Plone is migrating away from it or some long time developers are still using it. It's a large piece of legacy code that has no future - certainly not for new users or developers not already familiar with it.
Well, I don't know anything about what Plone is or isn't doing. No Plone was ever able to move to a different Zope version without rewriting basically everything, so maybe you think that's normal. It isn't like that for most everybody else though.
IMHO the way to treat a "large piece of legacy code" is *not* to break various things inside it because some other idea to do things seemed so much cooler a while back (but which we also abandoned, because we'll get rid of it all anyway).
The way to do that properly is to make it as stable an lasting as you can and let it stay alive till it falls over by itself. So if you think it's dead, OK, but there is no reason to actively kill it piece by piece.
Moving a "big old application" across multiple major versions at onece of any platform is likely to be painful: even projects which are careful about backward compatibility (Zope has historically been very good at this) will have issued deprecation warnings in the versions you skip. Your best bet would be to port the app stepwise to the latest release of each major version, noting and fixing the warnings as you go. Zope 2.12 - 2.13 is likely to be the biggest jump, because 2.13 includes lots of changes which *remove* functionality from Zope to optional add-ons. 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2qyo8ACgkQ+gerLs4ltQ4LxgCeMDpTlyI21tcIOSnyIthn55Qs cWIAn1AAOfjk4+OOjrX1phVRk2dxF51f =67vM -----END PGP SIGNATURE-----
On Sunday 17 April 2011, Tres Seaver wrote:
Moving a "big old application" across multiple major versions at onece of any platform is likely to be painful: even projects which are careful about backward compatibility (Zope has historically been very good at this) will have issued deprecation warnings in the versions you skip. Your best bet would be to port the app stepwise to the latest release of each major version, noting and fixing the warnings as you go. Zope 2.12 - 2.13 is likely to be the biggest jump, because 2.13 includes lots of changes which *remove* functionality from Zope to optional add-ons.
I do agree with this and I have been keeping my apps current so they run on zope 2.13 and overall this has not been a huge burden. The problem is that with this change the feature used is deprecated but the replacement is not really documented anywhere so how to upgrade is not remotely clear. Zope does need to change and grow and so long as I can keep it a viable platform for what I do I will probably stay on it since it just works so amazingly well. I would just like documentation for the new systems that replace deprecated features. How is someone supposed to write a new app that uses the new event system without docs for it? If nobody is going to use the new event system what is the point of it? I have spent some time looking at other frameworks and most just don't look very promising to me. For grok my biggiest issue was fail open. It looks like the default is allow everything unless explicitely denied and I feel that is just a recipe for disaster. Pyramid looks pretty good and it does have a security system that you can set to fail closed but still I have a massive investment in zope 2.x and I don't want to just throw that away for nothing. We still manage to massively outdo our competitors using much newer technology in time to get a solution done, in cost and in reliability. So I would just like to see zope 2.x remain a viable platform and if things are to be removed or deprecated the replacement systems need some level of docs. Idealy, if I could, I would make it so that varous manage_before* and manage_after* type events would just call the zope.lifecycle stuff as a compatibility layer so all the old code would go away but old apps would work and the code itself would serve as instructions on how to upgrade. That way CatalogPathAwareness would stay but basically just be a wrapper for zope.lifecycle if that is possible.
Am 17.04.2011, 13:46 Uhr, schrieb William Heymann <kosh@aesaeion.com>:
I have spent some time looking at other frameworks and most just don't look very promising to me. For grok my biggiest issue was fail open. It looks like the default is allow everything unless explicitely denied and I feel that is just a recipe for disaster. Pyramid looks pretty good and it does have a security system that you can set to fail closed but still I have a massive investment in zope 2.x and I don't want to just throw that away for nothing. We still manage to massively outdo our competitors using much newer technology in time to get a solution done, in cost and in reliability.
So I would just like to see zope 2.x remain a viable platform and if things are to be removed or deprecated the replacement systems need some level of docs. Idealy, if I could, I would make it so that varous manage_before* and manage_after* type events would just call the zope.lifecycle stuff as a compatibility layer so all the old code would go away but old apps would work and the code itself would serve as instructions on how to upgrade.
That way CatalogPathAwareness would stay but basically just be a wrapper for zope.lifecycle if that is possible.
Hi, it would be great to see the things happen that you wish but the fact is Zope 2 has lost most of its developers already. If you want something in there you have to be prepared to do it yourself. I'm still a huge fan of everything that Zope achieved and agree with you totally that it is still more capable in many respects than many competitors but the world has moved on and it is important to move with it. Zope 2 is largely in maintenance mode with things being removed from the core because there is no one prepared to maintain them and they are not considered essential by those who are maintaining Zope 2 and making sure it can run on modern systems, etc. I, for one, are very grateful that this work is being done. As for an explanation of how to use events or simply getting a grasp of using the ZCA in Zope 2 I can highly recommend Philip von Weiterhausen's book on Zope 3. In many ways this is the missing Zope manual. Fortunately, many Zope inspired projects have learned from our consistent failure to provide good documentation and insist on it being part of the project. A brief and personal summary of the difference between events versus "magic" manage_* methods: events are explicit, ie. you must register a subscriber to a particular event or explicitly notify that an event has happened. This is perhaps a bit verbose but it gives you more control and helps you break functionality out of bloated classes. The signatures for event subscribers does take a while to learn but is reasonable. I suppose that it would be possible to scan source code automatically for manage_* methods and try and register subscribers on the fly but this would be against the spirit of the ZCA. In reality decorator-based registration as practised in Pyramid and Grok is a good compromise. @Sascha I'm not sure if this will answer your question but you might want to look at how Products.CMFCore.CatalogAware works. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Sun, Apr 17, 2011 at 02:58:12PM +0200) Charlie Clark wrote/schrieb/egrapse:
As for an explanation of how to use events or simply getting a grasp of using the ZCA in Zope 2 I can highly recommend Philip von Weiterhausen's book on Zope 3. In many ways this is the missing Zope manual.
Charlie, I really like this quote from the Pyramid documentation: "While the ZCA is an excellent tool with which to build a framework such as Pyramid, it is not always the best tool with which to build an application due to the opacity of the zope.component APIs." - From my point of view, wearing my "application developer hat", event handling is YAGNI. In my estimate - - 90% of Zope Products/Apps only use manage_afterAdd or use none of manage_after* - - the other 9.9% use manage_afterDelete and/or some combination for handling copy+paste. - - The other 0.1% thought very hard to find something else they thought they needed to do with events. So a full feature, "we have it all for you" framework like Zope has been doing fine to offer these few in an easy and simple way. Pyramid gives me full event handling as an optional extra, because Pyramid is a "you pay only for what you eat" framework and I might not even need those few that Zope offers out of the box - or I might be in the 0.1% and need the full deal. Interfaces is even more YAGNI in the role of the application developer. (Which is what the pyramid doc is saying there IMHO.) I don't write a framework where you can swap out one templating system for another, I just write an app that is finished at one point in time. As for Philip's book, I guess you are aware that lots of it is already outdated. Something to keep in mind and tell people when one recommends that book. (Philip is well aware of that and his "in hindsight, the book should have been free/open" blog post is quite interesting.)
@Sascha I'm not sure if this will answer your question but you might want to look at how Products.CMFCore.CatalogAware works.
Thank you. This would answer my question if someone told me to take over maintenance of CatalogAware / CatalogPathAware in Products.ZCatalog and I'd have to rewrite it instead of just writing tests and if I then asked the question "where do I start?". Regards, Sascha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFNqwQhpYOq9ODq/IoRAs9VAKCAFxvCYu6QX2QSSfibt01rFAr2lQCfVezW NkycMDv2jMUXRLxcgC+GI7k= =xmWB -----END PGP SIGNATURE-----
Am 17.04.2011, 17:15 Uhr, schrieb Sascha Welter <zopelist@betabug.ch>:
Charlie, I really like this quote from the Pyramid documentation: "While the ZCA is an excellent tool with which to build a framework such as Pyramid, it is not always the best tool with which to build an application due to the opacity of the zope.component APIs." - From my point of view, wearing my "application developer hat", event handling is YAGNI. In my estimate - - 90% of Zope Products/Apps only use manage_afterAdd or use none of manage_after* - - the other 9.9% use manage_afterDelete and/or some combination for handling copy+paste. - - The other 0.1% thought very hard to find something else they thought they needed to do with events.
Actually, I am big fan of events - yes, you don't need them very often but they do solve provide a useful solution to some fairly common use cases. Of course, as you point out they are often best wrapped up in a higher level component. I'm not sure what your point with the numbers is about - you think event notifications and subscribers are overkill given that pretty much only manage_afterAdd and manager_afterDelete are used? Maybe, but I think that's semantics. The important thing for me is that there is no magic. As to the larger point of how suitable is the component architecture for application development I think the main point that Chris is making, and I hope he'll correct me if this is not the case, is that doing everything with the ZCA, especially with registration is counter-productive: pluggability is not really a design goal for an application.
So a full feature, "we have it all for you" framework like Zope has been doing fine to offer these few in an easy and simple way. Pyramid gives me full event handling as an optional extra, because Pyramid is a "you pay only for what you eat" framework and I might not even need those few that Zope offers out of the box - or I might be in the 0.1% and need the full deal.
I beg to differ: Zope's SimpleItem is anything but and it's bastard Plonish offspring Archetype causes even more by offering convenience at the cost of complexity. Zope as a full-featured framework is a misconception: it is an application.
Interfaces is even more YAGNI in the role of the application developer. (Which is what the pyramid doc is saying there IMHO.)
Interfaces suffer most from conceptional vagueness. As an attempt to document the intent of classes they suck - that is pretty much what docstrings are for. I have found them to be most useful as: a) marker's and b) form schema templates. Of course, b) is something probably something they really shouldn't be used. Now I tend to see them as markers first with the possibility of being expanded to full-blown interfaces if pluggability becomes desirable.
I don't write a framework where you can swap out one templating system for another, I just write an app that is finished at one point in time.
I think everyone agrees on this nowadays. I do, however, like the ability to swap out the backend for deployment purposes if required.
As for Philip's book, I guess you are aware that lots of it is already outdated. Something to keep in mind and tell people when one recommends that book. (Philip is well aware of that and his "in hindsight, the book should have been free/open" blog post is quite interesting.)
Some of the detail is pretty much out of date but I still think it is a great handbook on the component-based approach to application development. Speaking as someone who has no CS background and is only a part-time programmer I found it incredibly helpful in structuring my approach to problem solving and really benefited from the extensive explanation of some of the more esoteric stuff that has now become more or less standard.
@Sascha I'm not sure if this will answer your question but you might want to look at how Products.CMFCore.CatalogAware works.
Thank you. This would answer my question if someone told me to take over maintenance of CatalogAware / CatalogPathAware in Products.ZCatalog and I'd have to rewrite it instead of just writing tests and if I then asked the question "where do I start?".
I think I detect some irony there. Sorry that it doesn't help you. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Sun, Apr 17, 2011 at 07:10:07AM -0400) Tres Seaver wrote/schrieb/egrapse:
Moving a "big old application" across multiple major versions at onece of any platform is likely to be painful:
Tres, I know how to move an app to newer zope versions. My apps are enough well behaved to have survived since 2.7 with few changes and from 2.10 straight to 2.13 needed only very few adjustments so far. What I want to know: The term "CatalogPathAwareness" was not found in the archives of zope-dev in the last 6 years or so. Can any zope developer deprecate or remove things on their own without discussion? Removing CatalogAware/CatalogPathAware from Products.ZCatalog is one point in question. Removing manage_afterAdd et al is another. This will break lots of code out there that would happily run on otherwise. Regards, Sascha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFNqvR6pYOq9ODq/IoRAtLlAJ0Qq7lac8cldIn89BkyQx+iXI/V2ACgqkVg u0tT7DCxBN0sCyLbwffd5Hc= =G5S7 -----END PGP SIGNATURE-----
Am 17.04.2011, 16:08 Uhr, schrieb Sascha Welter <zopelist@betabug.ch>:
The term "CatalogPathAwareness" was not found in the archives of zope-dev in the last 6 years or so. Can any zope developer deprecate or remove things on their own without discussion?
Technically, yes. In general there is usually a request on the mailing list because another developer could just as easily put the removed feature back. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/17/2011 10:08 AM, Sascha Welter wrote:
(Sun, Apr 17, 2011 at 07:10:07AM -0400) Tres Seaver wrote/schrieb/egrapse:
Moving a "big old application" across multiple major versions at onece of any platform is likely to be painful:
Tres,
I know how to move an app to newer zope versions. My apps are enough well behaved to have survived since 2.7 with few changes and from 2.10 straight to 2.13 needed only very few adjustments so far.
What I want to know:
The term "CatalogPathAwareness" was not found in the archives of zope-dev in the last 6 years or so. Can any zope developer deprecate or remove things on their own without discussion?
"Code talks." Hanno deprecated the CPA base class in r115308 in August 2010 with the comment: Fully deprecate both CatalogAwareness and CatalogPathAwareness. They are untested and unused. Event subscribers for zope.lifecycleevents are the way to go. Note that this was in the midst of a set of *huge* improveements to the catalog (the query plan stuff), for which we should be very grateful: such improvements grant legitimacy to Hanno's judgement about the state of the code. Note that if you need time to finish revising code which depends on the deprecated components, you can pin "Products.ZCatalog<=2.13.99" until your code is ready: that is one of the beauties of moving the code into a separately-released distribution.
Removing CatalogAware/CatalogPathAware from Products.ZCatalog is one point in question. Removing manage_afterAdd et al is another. This will break lots of code out there that would happily run on otherwise.
'manage_afterAdd' and siblings have been deprecated for a *long* time (since Zope 2.9.0b1, 2005-12-06): http://svn.zope.org/Zope/tags/2.9.0b1/doc/CHANGES.txt?rev=40603&view=markup 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2rFogACgkQ+gerLs4ltQ78KQCgoEuO3hUUt4rokZ5qndyaRx1H sZIAnjrRVwoQQmW1ncBoPO1/eN10M8rw =AvWq -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres and all, so it looks like I came over as a total jerk who rides a personal attack on Hanno. That is of course not my intention, not at all. I am sorry for that. I am grateful for every improvement to the code and it looks like Hanno did a great job. I have expressed my regret for coming over to him like that in a personal mail to him too. What I did raise my voice for is the kind of backwards compatibility and dependability that keeps an old application in the game even with a new version of Zope, without having to go in and change everything. I want developers to keep an eye open for that, even if it's not what they need in their own work or if they believe that Zope is dead already. The case that some admin in some random company has this Zope application running somewhere and wants to move it to a new server and a new Zope version, I believe that case should not be answered with "go and write that application from scratch on some other framework". I also would like to insist that manage_afterAdd etc has been undeprecated in 2.12 both in code and in the documentation (CHANGES.txt). I will step down from my soap box in this matter now. Whatever happens, happens. Regards, Sascha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFNqzaQpYOq9ODq/IoRAnZgAKCe8YPhgKYh7do0faMIPi8+24bWMQCdEYNh GcPi/1e/cieih4xLoMRQCUg= =jQ9P -----END PGP SIGNATURE-----
participants (5)
-
Charlie Clark -
Hanno Schlichting -
Sascha Welter -
Tres Seaver -
William Heymann