- Zope-Dev - Zope lists

Quickie?
by Gerald Anderson 13 May '03

13 May '03

Hey all, I'm working on developing a Product and have run into a small, but annoying nag. I'm using the mx.DateTime object to get a little more functionality for my timekeeping. Everything seems to work fine until I try to go to the security management tab for the objects in question (ZM). I get the following: User Name (User Id) gander (gander) Request URL http://localhost:8080/G/One/manage_access Exception Type AttributeError Exception Value 'mx.DateTime' module has no attribute '__bases__' Traceback (innermost last): * Module ZPublisher.Publish, line 98, in publish * Module ZPublisher.mapply, line 88, in mapply * Module ZPublisher.Publish, line 39, in call_object * Module AccessControl.Role, line 188, in manage_access * Module Shared.DC.Scripts.Bindings, line 252, in __call__ * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec * Module App.special_dtml, line 174, in _exec * Module DocumentTemplate.DT_With, line 76, in render * Module DocumentTemplate.DT_In, line 625, in renderwob * Module AccessControl.Role, line 100, in permission_settings * Module AccessControl.Role, line 79, in ac_inherited_permissions * Module AccessControl.Role, line 563, in gather_permissions * Module AccessControl.Role, line 563, in gather_permissions * Module AccessControl.Role, line 556, in gather_permissions AttributeError: 'mx.DateTime' module has no attribute '__bases__' I've done a little homework and think I'm more confused when I started. It seems that __bases__ is supposed to contain a tuple with the classes base classes? It also looks as though this is supposed to be a Python attribute, but I can't seem to verify that. Why is it that Zope would require this, or a very popular library not contain it? Is it some new or deprecated issue? Could anybody tell me where to start looking for some answers on this? Am I going to have to drop the mx.DateTime? Is there some simple and silly solution? Any help would be most appreciated. Just for informational purposes, I'm a neophyte zope and python developer, but an otherwise experienced professional. Thanks in advance, Gerald -- Gerald D. Anderson Sr. Web Geek gander(a)mail.cox.smu.edu Southern Methodist University 214-768-3250 Edwin L. Cox School of Business - Technology http://www.cox.smu.edu/ “I suggest there is no such thing as a left or right. There is only an up or down... Regardless of their sincerity, their humanitarian motives, those who would sacrifice freedom for security have embarked on the downward path.”—Ronald Reagan

2 1

HTTP Compression granularity.
by Romain Slootmaekers 13 May '03

13 May '03

Yo, browsing through the code, and the changelist for 2.6 I found the HTTP compression feature. Apparently it's a thing you need to turn on in ZPublisher.HTTPResponse by changing an option in the code. (yuk :() This makes it an all or nothing feature. I'd like to have more granularity and want to be able to turn it on/off for all content in specific folders. Is this possible? TIA, Romain.

3 2

Re: [ZODB-Dev] Several reports about data loss after packing
by Jeremy Hylton 13 May '03

13 May '03

On Mon, 2003-05-12 at 09:07, Maik Jablonski wrote: > [Sorry for cross-posting on zope-dev & zodb-dev, but it seems very > important to me (and maybe others suffering from data loss)] (I replied separately to zope(a)zope.org just now.) This bug was fixed a couple of weeks ago. Here's the original report: http://mail.zope.org/pipermail/zodb-dev/2003-May/004945.html Given the large number of people who have been affected, we've decided to backport the code to the Zope 2.6 branch after all. I'll send a note when the backport is done. Jeremy

1 0

CVS Head Zope Win32 build, mkzopeinstance, no runzope.py generated
by Jeff Kowalczyk 12 May '03

12 May '03

Thank you to the developers who've taken such strides to enable win32 builds from source, this is something I've wanted to do for a long time. I think I'm only one step away from getting it to run, the final mkzopeinstance step doesn't seem to write the runzope.py on my configuration. Particulars: Python 2.2, win32all installed in "C:\Program Files\Python\" Built with: c:\archives\cvs\zope>python inst\configure.py --prefix=\progra~1\zope nmake build, nmake install worked fine, but for one warning at the end: (...) creating C:\progra~1\zope\skel\var copying skel\var\README.txt->C:\progra~1\zope\lib\python\..\..\skel\var warning: ZopeInstall: modules installed to 'C:\progra~1\zope\lib\python\', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself Zope binaries installed successfully. Now run '"C:\Program Files\Python\python.exe" C:\progra~1\zope\bin\mkzopeinstance' C:\Program Files\zope\bin>"C:\Program Files\Python\python.exe" C:\progra~1\zope\bin\mkzopeinstance --user Admin:mypass C:\progra~1\zope Dir of files now in C:\Program Files\zope\bin mkzeoinstance mkzopeinstance runzope runzope.bat zconfig zopectl Contents of runzope.bat: set PYTHON=C:\Program Files\Python\python.exe set ZOPE_HOME=C:\progra~1\zope set INSTANCE_HOME=C:\progra~1\zope set CONFIG_FILE=%INSTANCE_HOME%\etc\zope.conf set PYTHONPATH=%ZOPE_HOME%\lib\python "%PYTHON%" "%ZOPE_HOME%\bin\runzope.py" -C "%CONFIG_FILE%" %1 %2 %3 %4 %5 %6 %7 Since runzope.py is never generated, is this the mkzopeinstance silently telling me that I need c:\progra~1\zope\lib\python added to the python 2.2 path? How do I configure that? I've only ever used sys.path.append(). Thanks for any insight you can provide. I'm really looking forward to getting this and mkzeoinstance going.

1 0

Several reports about data loss after packing
by Maik Jablonski 12 May '03

12 May '03

Hi, in the last weeks there were several reports (recently two reports on zope(a)zope.org) about data loss after packing the ZODB. I've encountered the problem two times in production environments for myself... and I'm not lucky about that fact. See: http://www.dzug.org/mailinglisten/zope-org-zope/archive/2003/2003-05/105250… http://www.dzug.org/mailinglisten/zope-org-zope/archive/2003/2003-05/105273… For me all the descriptions seem to be related to: http://collector.zope.org/Zope/875 Maybe it's only a problem when ZEO is used (I'm not sure about this). I don't have any idea how to fix this issue, but I think this one should be fixed as soon as possible. Cheers, Maik

3 2

Re: [Zope-dev] PROPOSAL: ZODB Relationships
by Lennart Regebro 12 May '03

12 May '03

Sorry, put this in the wrong forum... -------- Original Message -------- Subject: [Zope] Re: [Zope-dev] PROPOSAL: ZODB Relationships From: Lennart Regebro <lennart(a)regebro.nu> Jean Jordaan wrote: > You could still delete the storage if you wanted to kill all stored > relations, couldn't you? Well, yes, which yet again makes me think this is not a good path forward. It feels to me that the relation either should be stored in the object, and indexed somewhere, or there should be one central secret invisible storage. The relationship between two objects should not be deletable from "outside" the object, that seems really weird. If the relationship really is stored outside the object, then the only way to delete that relationship should be through an API. (With reasonable exceptions, such as deleting the ZODB, and setting Application.__relations = None, or something like that).

1 0

Bobo-Exception-.. can produce rfc non compliant headers in response.
by Romain Slootmaekers 11 May '03

11 May '03

Yo, in case of an exception, the following headers, can produce non compliant HTTP response headers. Bobo-Exception-File Bobo-Exception-Type Bobo-Exception-Value Especially the Bobo-Exception-Value header, which is a chopped off version of the body of the response, is a cause of problems. fe -------------- included example ----------------- Bobo-Exception-Value: <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml"> <wml> <card> <p -------------- /included example ---------------- Normally, your browser doesn't barf on this, but browsers on small devices (like mobile phones) and their gateways are way more picky :( I have more than one problem with these headers: 1) most important: unpredictability of the RFC compliance. not a good thing. 2) security related: they give out way to much information to be confortable with. a client doesn't have any business with the absolute path to your zope install (Bobo-exception-File) and you even get these even when not running with the -D option. Although not enough info to hack/crack/whatever the machine/server it gives a hacker something concrete to work with. 3) usefulness: what do you gain from having these headers anyway? you have the error log on server side that contains the same information in another form. Is there still anybody out there who uses this ? if not, it's better to throw the whole thing out of the codebase, no ? Romain.

5 9

Great opportunity
by senserospj＠freg.com 10 May '03

10 May '03

1 0

PROPOSAL: ZODB Relationships
by roche＠upfrontsystems.co.za 09 May '03

09 May '03

We finally have a proposal out for ZODB relationships. This proposal presents an API for relationships, summarises ideas and contributions from a lot of people and was fuelled by the recent discussions about relationships on Zope3-dev and Zope-dev. http://www.zope.org/Members/upfront/ZODBRelationships Your comments would be appreciated. Shane, thanks for all your help! -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za

9 15

RE: [Zope-dev] RFC: RelationAware class for relations between obj ects
by sean.upton＠uniontrib.com 08 May '03

08 May '03

So the answer of what acts as a reference id for the referred-to object is: "Whatever the best id that your framework provides you is." If your framework is Zope3, a hubid is what you should use. In Zope2, a path or tuple containing (storagename, oid). In ZODB-sans-Zope, an oid (or a (storagename, oid) tuple with the storagename an empty string). I wonder if a single framework could adapt to fit the needs of all 3? It seems doable (different plugins to store the IDs, 'traverse' to the objects), I think... Sean -----Original Message----- From: Shane Hathaway [mailto:shane@zope.com] Sent: Thursday, May 08, 2003 12:15 PM To: sean.upton(a)uniontrib.com Cc: maxm(a)mxm.dk; zope-dev(a)zope.org Subject: Re: [Zope-dev] RFC: RelationAware class for relations between obj ects sean.upton(a)uniontrib.com wrote: > More in response to Shane than to Max M: I thought that one of the > continuing justification for ObjectHubs was that hubids were consistent > across multiple mounted storages, but oids were not? How could the > universal id problem be addressed at a lower level than Zope2 or Zope3 in > this case? When relationships are applied to Zope, they will always use hub IDs. Outside Zope, mounting and traversal don't always apply. > Then it starts to get amusing. One of the primary reasons for the > objecthub was to enable relations. So if the relations get implemented > in in ZODB but need some functionality, will it not end up as a > duplication of efforts? Don't assume there is actually any separate effort going on. The point of all of this talk is to discover in what ways the proposed relationship management is insufficient. Once understood, the ideas can come together. Shane

3 2