Zope-Dev August 2002

zope-dev@zope.dev

92 participants
88 discussions

How to override __getattr__ and not break acquisition
by Erik A. Dahl 17 Oct '02

17 Oct '02

Ok I need to override __getattr__ in one of my product classes. I'm sure this is killing acquisition but not sure about the persistence stuff (I think this is working). Is there a way to make this work? Here is what I'm doing: def __getattr__(self, name): if name == 'myattr': return self.myattr() I assume that somewhere in the Acquisition code there is a __getattr__ but I can't find it. I tried calling Implicit.__getattr__ but its not there. If some one has an example that would be great. -EAD

7 14

Unit testing on win32 with FAT requires patch to custom_zodb.py, is this a known issue?
by Craeg K Strong 11 Sep '02

11 Sep '02

Hello: In order to use the unit testing facility for my custom Zope Products under FAT in win32, I had to do the following: In the file name:: [ZOPE]\lib\python\Testing\custom_zodb.py Where ZOPE stands for the directory in which you installed Zope, Change line number seven:: Storage = DemoStorage(base=FileStorage(dfi,read_only=1), quota=(1<<20)) to instead read:: Storage = DemoStorage(base=FileStorage(dfi, read_only=0), quota=(1<<20)) My guess is that FAT does not support the read_only attribute as required. Is this a known issue? Am I missing something? Thanks very much! --Craeg

3 6

Proxy Object / __getattr__ / Acquisition
by sean.upton＠uniontrib.com 30 Aug '02

30 Aug '02

I am trying to implement a proxy class (specifically for the purposes of multi-versioned document objects (folderish proxies that contain the object that they proxy to). I am using __getattr__ within my product, and the code pasted below works, and does not "break" Implicit acquisition (because the object that _CurrentVersion points to is subclassed from SimpleItem, which implements Implicit Acquisition). However, because of the way that this messes with Acquisition, certain things like accessing the ZMI pages or acquired methods can be quite slow (but work). I suspect that this is because an instance of this class actually acquires items through the item it proxies to, which conveniently is contained inside it, which makes acquisition work for the instance of this class (albeit magnitudes slower). I would really like to make this perform better and act properly, but I'm at a loss as to the right way to do this. Thoughts? Sean class MVProxy(Folder): """ Object acting as proxy to multiple document implementations serving for each version of this document; this is a proxy object class Subclasses OFS.Folder.Folder """ def __init__(self, id, title=''): self.id = id self.title = title timestamp = str(int(time.mktime(time.localtime()))) currentId = id+'_'+timestamp current = DocumentCoreImpl(currentId, title) self._setObject(currentId, current) self._CurrentVersion = current def __getattr__(self, name): return getattr(self._CurrentVersion, name) +----------------------------------------------------------- | Sean Upton | Site Technology Supervisor SignOnSanDiego.com | Development & Integration The San Diego Union-Tribune | 619.718.5241 sean.upton(a)uniontrib.com | PATH_TO_THE_DARK_SIDE = 'c:\winnt\system32' +-----------------------------------------------------------

4 3

Re: [Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/ZPublisher - xmlrpc.py:1.14
by Casey Duncan 30 Aug '02

30 Aug '02

I agree that error values containing html are pretty evil, but I think they go back to the days before we had any notion of using Zope beyond direct web publishing. Many of these originate from the response object itself, so I plan to override them in the xml-rpc reponse class. In any case, in the process of refactoring my first try (below) at untangling error values in xmlrpc, I found a small diamond in the rough that is worth pointing out: Zope response objects have a class attribute "_error_format" that is set to "text/plain" in BaseResponse and overridden as "text/html" in HTTPResponse. I overrode it back to "text/plain" in xmlrpc.Response in my latest check-in. Zope's top level exception handler (in Zope/__init__.py) sniffs this value and only fires off the rendering of standard_error_message if response._error_format is 'text/html'. So this change alleviates much of the noise in the xmlrpc fault string and eliminates the need for much of the formatting hacks I put in. The refactored xmlrpc exception handler still strips tags from the error_value, I could be convinced to escape them instead, if that's what user's would prefer. In any case I plan to fix the most egregious offenders (like not found errors) entirely by making them a plain text message for xml-rpc. -Casey On Friday 30 August 2002 12:16 pm, Florent Guillaume wrote: > Casey Duncan <casey(a)zope.com> wrote: > > Update of /cvs-repository/Zope/lib/python/ZPublisher > > In directory cvs.zope.org:/tmp/cvs-serv24443 > > > > Modified Files: > > xmlrpc.py > > Log Message: > > Improved error output for xmlrpc faults > > > > - Value is stripped of HTML tags and minimally formatted > > + # Strip HTML tags and format the error value > > + v = str(v) > > + v = re.sub(r"<br\s*/?>", "\n", v) > > + remove = [r"<[^<>]*>", r"&[A-Za-z]+;"] > > + for pat in remove: > > + v = re.sub(pat, " ", v) > > + v = re.sub(r"\n(?:\s*\n)+", "\n\n", v) > > + > > + from Globals import DevelopmentMode > > + if DevelopmentMode: > > + from traceback import format_exception > > + value = ''.join(format_exception(t, v, tb)) > > + else: > > + value = '%s\n\n%s' % (t, v) > > + > > IMHO this goes to show that the error value should never have contained > HTML in the first place. I think error values should be defined as pure > text, and the HTML publishing would html_quote it as needed, and the > XMLRPC publishing would do what it deems. > > Florent

1 0

Re: [Zope-dev] find unused objects: hopefully the last misunderstanding... :o)
by THerp＠apriori.de 30 Aug '02

30 Aug '02

Original problem: > I have lots of scripts, dtml methods etc. everywhere which are > perfectly well-known to the ZODB, nothing wrong with that, but which > are simply not used by me anymore. No usage from other scripts nor > methods nor documents. And these buggers I'd like to find. @Steve: > You forgot to post my suggestions: Sorry, no offense meant. Here they are: > You can use Zope Find to get a list of them, and then manually audit > them. You could instrument such methods to output logging, and check the > logs every so often to see what is typically being used. > You could use Zope Find to see if the name of particular methods is used > within other methods. Well, I simply liked to know if anyone had already done it, so I simply forgot to add them. @ Jean: > They're impossible to find :)) Take for example the 'index_html' of > a folder: nothing else in my Zope app refers to it. But whenever > someone browses to http://my.zopeserver.com/folder they see that > 'index_html'. No automatic method can guess what objects have become > irrelevant. Well, the search seed could be an optional argument w/default value 'index_html'. > If you want to find everything that isn't refered to by another Zope > object, you could use 'sitecopy' to make a filesystem copy of > everything in your ZODB, 'ls -R' to get a list of filenames, and > 'grep -r filename *' for each filename in the list. If the grep > returns nothing, nothing refers to that object. > > You could do the same kind of thing ('ls -R' and 'grep') from the > Zope Management Interface using Jerome Alet's zshell. Interesting suggestions! Of course, these unfortunately won't handle the acquisition thing correctly. To dream a dream: Consider a tab for folderish objects which allows to search them for unused scripts/methods/... (after pressing a button because it would possibly take a while), producing a sortable list of links, with checkboxes for deletion... Consider a tab for methods... which allows to parse them and produces a sortable list of links to the other referenced methods... Maybe I'll write something like that, but it would be my very first Zope product. By the way, new question: Is this the correct mailing list for such suggestions? If not, which one is it? Tobias Herp

3 4

Re: [Zope-dev] find unused objects: hopefully the last
by Charlie Reiman 30 Aug '02

30 Aug '02

As people already noted, this is essentially impossible for a bunch of reasons. ...but... You could add to Zope some sort of access counters on all objects. You could reset this on a live site, twiddle your thumbs for a week, then dump those counters. Objects with the smallest counters are clear candidates for removal but you would have to make the decision with your brain or other equivalent thought-organ. No automated process can remove all dead objects safely in a system like Zope. There would be a fairly large performance impact if those counters live in the objects since then the assumption the object DB is primarly a read-only resource would be false. However you could keep it in-core since the counters would be just a guide and it wouldn't be much larger than the DB index. In fact I bet you could attach such a sytem to the ZODB index logic pretty easily... Hmm... I think I'm talking beyond my knowledge. I think I'll shut up now.

1 0

Potential Improvements for xml-rpc debugging
by Casey Duncan 30 Aug '02

30 Aug '02

I am working on improved xml-rpc fault output because I find the current output from Zope less than useful. Basically what my version does is strip the html tags from the error value returned from Zope/standard_error_message, formats it in a simple way (basically justs trims line breaks down) and then generates a formatted traceback (if you are in debug mode) as the xml-rpc fault string. If you aren't in debug mode then it just outputs the error type and the formatted value as the fault string. Now my question is whether this is a good thing in general. I like it especially when accessing Zope using Python's xmlrpclib, but do any of have reasons for keeping the html tags in the fault string? Thought I would ask before I check this in. -Casey

3 2

Re: [Zope-dev] find unused objects: hopefully the last misunderstanding...
by THerp＠apriori.de 30 Aug '02

30 Aug '02

* > Starting at root, check all objects if they are referenced, * > and produce a list of those which are not, for cleanup purposes. * Packing the database cleans up in this manner. Oh well. Third try: I know about the 'pack database' button. Garbage collection of this kind is not my problem. I have lots of scripts, dtml methods etc. everywhere which are perfectly well-known to the ZODB, nothing wrong with that, but which are simply not used by me anymore. No usage from other scripts nor methods nor documents. And these buggers I'd like to find. Finally unmistakeable? Tobias Herp

3 2

Re: [Zope-dev] find unused objects: hopefully the last misunderstanding... :o)
by THerp＠apriori.de 30 Aug '02

30 Aug '02

* > I have lots of scripts, dtml methods etc. everywhere which are * > perfectly well-known to the ZODB, nothing wrong with that, but which * > are simply not used by me anymore. No usage from other scripts nor * > methods nor documents. And these buggers I'd like to find. * There is no easy way to find such things. * Especially given acquisition, and the dynamic nature of Zope. Finally we got it :o) Ok, the reason for me posting this question was the difficult nature. So I take your answer as a 'no' to my original question if anyone has already written such a script. Maybe this would be a good thing to accompany future Zope versions. There could be a tab which shows all objects which are called explicitely by the actual one in a sortable list. By the way: is this the correct mailing list for such suggestions? If not, which one is it? Thanks, Tobias

2 1

Site-crawler (find unused objects)
by THerp＠apriori.de 30 Aug '02

30 Aug '02

Hi, has anyone written a script which crawls a site and lists all objects which aren't referenced anymore? Tobias Herp Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das un- erlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev August 2002