- Zope-Dev - Zope lists

How to delete dodgy zope.org issues
by Chris Withers 26 Mar '06

26 Mar '06

Hi All, Just so people know, if you see spoor in the collectors, Tres wrote a handy script/template to let you delete them. You'll need to be a manager in /Collectors or above. If you are, just go to: http://www.zope.org/Collectors/remove_dodgy_issue Fill in the boxes and click the button. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

1 0

I agree that ZClasses should stay. I will volunteer
by Christopher Lozinski 25 Mar '06

25 Mar '06

I am interested in maintaining them, documenting them, and upgrading them. I have been through the code a number of times, and if someone would spend 15 minutes explaining the high level design decisions, I could probably keep them up to date. Why do they have multiple properties on a property sheet, instead of having a list of independent data types? I am also very interested in versions, and maintaining versions. Versionning and ZClasses make the fastest single user development environment I have ever seen in my life. If your company can afford file based development, great, but some of us live on the income from our web sites, and really want to develop fast. And I object to the statement that "most people with solid backgrounds". I would prefer if you said that: "In certain circumstances ZClasses makes sense, in other circumstances, file based development makes better sense. In some cases Plone is better, in some cases Zope is better, in some cases Ruby on Rails is better, in some cases Zope3 is better". Different situations require different choices. Regards Chris

4 3

IMO ZClasses should stay
by Jim Fulton 25 Mar '06

25 Mar '06

On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better, Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

5 12

Upcoming Zope 2.X releases
by Andreas Jung 25 Mar '06

25 Mar '06

As announced earlier I plan to release Zope 2.8.7 and 2.9.2 by next Monday...so as always: any pending fixes should be commited until Monday. Andreas

2 1

Question about manage_afterAdd in 2.9.1
by Chris Withers 20 Mar '06

20 Mar '06

Hi All, I've started seeing warnings like this with an instance I'm moving from Zope 2.7 to 2.9: C:\Zope\2.9.1\lib\python\OFS\subscribers.py:74: DeprecationWarning: Products.CookieCrumbler.CookieCrumbler.CookieCrumbler.manage_afterAdd is deprecated and will be removed in Zope 2.11, you should use event subscribers instead, and meanwhile mark the class with <five:deprecatedManageAddDelete/> DeprecationWarning) Is there an example of exactly what I need to add and where? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 2

[Zope2] ZODB load optimization ineffective due to ExtensionClass flaw
by Dieter Maurer 20 Mar '06

20 Mar '06

The ZODB allows to include the class (a reference to it) into persistent references in order to avoid loading the object state when a ghost object needs to be created for the persistent reference. For this to work, the class must not require arguments to "__new__". The ZODB checks whether the class defines a "__getnewargs__" method. It it does, the ZODB concludes that its "__new__" might need arguments and does not try to optimize. Unfortunately, "ExtensionClass.Base" defines "__getnewargs__". It is the base class for all Zope2 classes. Zope2 persistent references are not optimized... An analysis of our application revealed that the missed optimization opportunity increases the amount of storage loads by a factor of 4 to 5. Storage loads are often the dominating factor -- especially for searches. @Jim: Is the "__getnewargs__" definition in "ExtensionClass.Base" vital? It returns the empty tuple. Thus, there seems to be a chance to get rid of it. I know that some code (especially in "ExtensionClass/picke/pickle.c") needs to be changed as it depends on the existence of "__getnewargs__". If you think, there is a chance to get rid of "__getnewargs__", I can do the work and put the changes into the collector. Zope2 might become a bit faster... -- Dieter

3 3

New mailing list: Checkins@zope.org for all checkin messages
by Jim Fulton 18 Mar '06

18 Mar '06

I've set up a new mailing list that gets all checkins for the zope.org CVS and Subversion repositories: http://mail.zope.org/mailman/listinfo/checkins Note to contributors: Only members can send messages to this list. This means that you will get messages for a while when you check in saying your messages are being held for moderation. I am moderating the list. When I see legitimate held messages, I'll add the sender to the list of valid non-member senders. So if you don't want to subscribe, you don't have to. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

3 4

Default skin pain
by Philipp von Weitershausen 18 Mar '06

18 Mar '06

Hi there, Zope 3 has the concept of a default layer. This is a request interface that most skins derive from. It is also the default request interface that browser views are registered for if they don't specify another one using the 'layer' argument. Zope 3 also has the concept of a default skin. This is a request interface that is specially registered and applied to the request after it has been created. This last bit is important because you want all subsequent view look-ups to take the default skin into account. Since most browser views are registered for the default layer interface and most skins derive from the default layer interface, not setting the default skin on the request as early as possible would result in most views not being found. Of course, ZPublisher doesn't apply the default skin to the request after its creation. Therefore, Five has to do a hack: upon the first Five-style traversal (that might involve Zope 3 views), it puts the default skin on the request. There are two problems with this approach: * Previous traversal steps could have already set a different layer (or skin) on the request. This is a valid usecase (e.g. ++skin++ can be used for this). Five's behaviour would possibly make the previously applied layers or skins ineffective again. Five tries to be as uninvasive as possible by only doing this when the request doesn't have an ILayer interface yet. Problem is, the notion of all layer interfaces providing ILayer is going to go away (it's already deprecated on the Zope 3 trunk). * More importantly, you sometimes might want to do view lookup before the first Five-style traversal happens. Then you're dealing with a virgin request that doesn't have the default skin installed (and therefore neither the default layer in most case) and your view look-ups would probably fail because the views were registered for the default layer. The latter point is an issue in Plone, by the way. I would propose to remove the Five hack and "properly" set the default skin right after the request has been created. This would be in ZPublisher.Publish.publish_module_standard. (ZopeTestCase would also have to be fixed up so that each test gets its individual request object [all tests currently share the same one!] and that the request would also have the default skin set from the beginning) Philipp

2 3

PDBDebugMode 0.1 Release
by Ross Patterson 17 Mar '06

17 Mar '06

http://www.zope.org/Members/rossp/PDBDebugMode PDBDebugMode - PDB post-mortem debugging on exceptions when debug-mode=on If a relevant error log object is found, exceptions included in the error log's ignored exception types will be ignored and the debugger won't be invoked. It also enables the import of the pdb module in unprotected code. On encountering an error, the port-mortem debugger is invoked with the error's traceback. Once in the debugger you can examine objects, variables, etc. at all levels of the call stack. This is, of course, extremely useful for debugging. Since it only does anything if the instance is running with debug-mode=on, I find this product useful not only for debugging on my development instances, but also for doing quick emergency debugging on a live production site. IOW, if the problem is only reproducable on the production site but not on my development instance, I'll restart the production instance in debug-mode with pdb in emacs, reproduce the error, inspect the call stack. Ross Patterson

5 8

RE: How to delete an object given a path in Zope
by Takahashi, Michael 16 Mar '06

16 Mar '06

Hi Suresh, I've actually tried that. The problem I run into is that the folder in my path contains a dash. When I call manage_delObjects on the following: obj = context.restrictedTraverse('webcasts/courses/2005-2006/temp') id = obj.getId() context.webcasts.courses.2005-2006.manage_delObjects(id) Python complains about the '-' in 2005-2006 on the third line. So my thought was that if you had the object reference you could somehow delete that reference like so: obj = context.restrictedTraverse('webcasts/courses/2005-2006/temp') id = obj.getId() obj.manage_delObjects(id) This however does not work. It gives the following error: Error Type AttributeError Error Value temp Side note: I'm running Zope 2.7.6 Thanks, Mike -----Original Message----- From: suresh [mailto:suresh_vv@yahoo.com] Sent: Wednesday, March 15, 2006 3:09 AM To: Takahashi, Michael Subject: Re: How to delete an object given a path in Zope >> Takahashi, Michael wrote: >>> >>> I am trying to figure out how to delete an object in Zope given a path. >>> >>> >> <snip> >> >>> >>> Any help is greatly appreciated. >>> You want to call manage_delObjects on the parent folder and give it the list of ids.

4 3