[Zope-dev] Utility factory handling for zope.component
Tools like GenericSetup which deal with mangement of utility registration are a bit handicapped at the moment: even though you can register a utility using a factory the utility registration itself only runs the factory methods but does not keep any information on it. As a result you can not round-trip utility registration information or check if the current configuration has changed from an original configuration. To fix that I made a wichert-utility-factories branch of zope.component which adds the factory information to the utility registration. All changes are fully backbwards compatible at both the API and persistence level. If there are no objections I intend to merge the branch to trunk in a few days. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Tue Jul 22 11:00:00 2008 UTC to Wed Jul 23 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue Jul 22 21:03:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009895.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:04:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009896.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:06:12 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009897.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:07:42 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009898.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue Jul 22 21:09:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-July/009899.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Deprecation Warning
Hi everybody, While porting Zope2 on Python2.5, I am now trying to remove the deprecation warnings.Most of them are due to the raising of string exceptions. One of such warnings in the module Products is /home/zope/ztrunk25/lib/python/OFS/SimpleItem.py:248: DeprecationWarning: raising a string exception is deprecated raise error_type, v, tb These warnings can be removed by changing these string exceptions to class based exceptions. Can anyone suggest how these changes can be made? With regards Vyshakh ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Deprecation Warning
On Wed, Jul 23, 2008 at 14:03, vyshakh krishnan [EMAIL PROTECTED] wrote: Hi everybody, While porting Zope2 on Python2.5, I am now trying to remove the deprecation warnings.Most of them are due to the raising of string exceptions. One of such warnings in the module Products is /home/zope/ztrunk25/lib/python/OFS/SimpleItem.py:248: DeprecationWarning: raising a string exception is deprecated raise error_type, v, tb These warnings can be removed by changing these string exceptions to class based exceptions. Can anyone suggest how these changes can be made? Well, typically you create classes based on Exception or BaseException, and use them instead. Maybe you could expand a bit on what your worries are? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Utility factory handling for zope.component
On Wednesday 23 July 2008, Wichert Akkerman wrote: If there are no objections I intend to merge the branch to trunk in a few days I am uncomfortable with the way you approached this. I think there are at least two other possibilities that I can see without having looked closer: 1. Use the info object. The point of the info is to contain this sort of information. 2. Make the component have a factory attribute. I have done this at some places for APIDOC as well. Option 1 seems the cleanest because it was designed d for this. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Utility factory handling for zope.component
Stephan Richter wrote: On Wednesday 23 July 2008, Wichert Akkerman wrote: If there are no objections I intend to merge the branch to trunk in a few days I am uncomfortable with the way you approached this. I think there are at least two other possibilities that I can see without having looked closer: 1. Use the info object. The point of the info is to contain this sort of information. Which info object are you referring to? The only information I could see for utility registration is a tuple, not an object. This is used to build the UtilityRegistration object when querying registration information, and I added a factory method there. 2. Make the component have a factory attribute. I have done this at some places for APIDOC as well. Why would a component need to know how it was created? I can envision that a component may very well have an attribute named factory for something else entirely. Wichert. -- Wichert Akkerman[EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Utility factory handling for zope.component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: Tools like GenericSetup which deal with mangement of utility registration are a bit handicapped at the moment: even though you can register a utility using a factory the utility registration itself only runs the factory methods but does not keep any information on it. As a result you can not round-trip utility registration information or check if the current configuration has changed from an original configuration. To fix that I made a wichert-utility-factories branch of zope.component which adds the factory information to the utility registration. All changes are fully backbwards compatible at both the API and persistence level. If there are no objections I intend to merge the branch to trunk in a few days. +1. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIh0/1+gerLs4ltQ4RAqvmAJ9ZhukVeDLQ+MiBTTYtDC6NkEEwYACcCIUn CpxkKLgOfJjmdulFMgOuqtE= =rKeM -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Deprecation Warning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 vyshakh krishnan wrote: Hi everybody, While porting Zope2 on Python2.5, I am now trying to remove the deprecation warnings.Most of them are due to the raising of string exceptions. One of such warnings in the module Products is /home/zope/ztrunk25/lib/python/OFS/SimpleItem.py:248: DeprecationWarning: raising a string exception is deprecated raise error_type, v, tb These warnings can be removed by changing these string exceptions to class based exceptions. Can anyone suggest how these changes can be made? That code is not in the Products module: it is inside OFS.SimpleItem's 'raise_standardErrorMessage' method. Note that the method explicitly converts the error_type to a string above: that is the source of the DeprecationWarning, almost certainly, as there should be no remaining traces of explicitly-created string exceptions anywhere in the Zope codebase. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIh1FR+gerLs4ltQ4RAt7AAJ96zocnGl6fMw6qKfLn59/bV6/ZyQCcCdL+ Vqw6L0yBM1eQ4z0D3yxS0kM= =2F4j -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Utility factory handling for zope.component
Wichert Akkerman wrote: Stephan Richter wrote: On Wednesday 23 July 2008, Wichert Akkerman wrote: If there are no objections I intend to merge the branch to trunk in a few days I am uncomfortable with the way you approached this. I think there are at least two other possibilities that I can see without having looked closer: 1. Use the info object. The point of the info is to contain this sort of information. Which info object are you referring to? The only information I could see for utility registration is a tuple, not an object. This is used to build the UtilityRegistration object when querying registration information, and I added a factory method there. I think Stephan is referring to the (formerly) last item of the tuple, which is available as utility_reg.info. It contains information about how the component was registered, for instance the ZCML file name + line number. It looks like Stephan is suggesting to do something like this: component = factory() registry.registerUtility(component, info=InfoAbout(factory)) whereas Wichert's approach allows you to write: registry.registerUtility(factory=factory) I prefer Wichert's approach. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Deprecation Warning
Hello everyone, Since the deprecation warning is due to the conversion of error_type into string by 'raise_standardErrorMessage' method, is it still necessary to use new user defined Exception class or do we want to modify the function 'raise_standardErrorMessage' . ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Utility factory handling for zope.component
On Wednesday 23 July 2008, Philipp von Weitershausen wrote: I think Stephan is referring to the (formerly) last item of the tuple, which is available as utility_reg.info. It contains information about how the component was registered, for instance the ZCML file name + line number. It looks like Stephan is suggesting to do something like this: component = factory() registry.registerUtility(component, info=InfoAbout(factory)) whereas Wichert's approach allows you to write: registry.registerUtility(factory=factory) I prefer Wichert's approach. Oh, I thought the component argument was still required making factory a documentation artifact. In this case I am okay. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Deprecation Warning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: On Wed, Jul 23, 2008 at 20:26, vyshakh krishnan [EMAIL PROTECTED] wrote: Hello everyone, Since the deprecation warning is due to the conversion of error_type into string by 'raise_standardErrorMessage' method, is it still necessary to use new user defined Exception class or do we want to modify the function 'raise_standardErrorMessage' . We want to NOT raise a string. But an Exception object. That's pretty much it. As earlier: please share your worries about this. It sounds like a rather trivial code change, but you don't seem to think so, and we can help better if you explain why. Exactly: I made a pass through the code in November 2003 ripping out string exceptions, but must have missed this one[1]. Please just change the 'raise_standardErrorMessage' method to avoid converting 'error_type' to a string; then, if anything is actually passing 'error_type' as a string, we should fix *that* code. [1] $ CVSROOT=ext:cvs.zope.org:/cvs-reposotiry \ cvs diff -r tseaver-strexp_delenda-base \ -r tseaver-strexp_delenda-branch Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIh7GI+gerLs4ltQ4RAn4iAJ9DC8tVOBLbGhsQxtxni5gjTPLrNQCgkv6u nh0Wr9O4Cs2CePPM5MnhJ3o= =a32S -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )