December 2000 - Zope-Dev

Re: [Zope-dev] case insensitive sorts
by Dieter Maurer 03 Jan '01

03 Jan '01

Andy McKay writes: > .... what does anyone else think.... I would not like it. Dieter

5 12

[ZPatterns] DataSkin object ownership
by BS 03 Jan '01

03 Jan '01

Do DataSkins have ownership? I want to give multiple users the ability to add objects to a rack and only allow the 'owner' to view/edit the object. When a user adds a DataSkin to a rack does he get ownership of the object? I can't seem to get the ownership information for these objects. Is there a way to do this? BTW - I'm talking about virtual object that totally live in MySQL. Thanks, -Ben

4 5

Re: [Zope-dev] RE: objectIds accessiblilty & and a proposal
by Dieter Maurer 03 Jan '01

03 Jan '01

Toby Dickenson writes: > > ... protocol specific access rights ... > Please No. > > Zope security is complex enough without having to worry about > different security settings depending on how a method is accessed. > (And we should have a lower tolerance for complexity when it applies > to security) > > If a user has permission to access a method then he should be able to > access it any way (xmlrpc, ZPublisher, DTML, PythonMethods) I agree with you mostly. But it might be a significant difference, whether you access via HTTP or HTTPS or even a protocol that provides trusted authentication. Furthermore, I would not bring DTML and web access on the same level: There are objects, that should be usable by Anonymous inside DTML but should not be viewable over the web (as they will only confuse). All page components (such as "standard_html_header/footer") fall into this category. Dieter

3 2

case insensitive sorts
by Andy McKay 03 Jan '01

03 Jan '01

Minor nit and patch: I've found that really for me what users want to see is a case insensitive sort of objects, not the current python case sensitive sort. So that the order of objects from dtml-in and tree is a, A, b, B as apposed to A, B, a, b. Anyway Ive patched dtml-in and dtml-tree to do this sort on a ignore_case tag. Is this useful to anyone else? And Ive thought of patching my Zope so this is the default behaviour.... what does anyone else think. The next thing to patch is ZCatalog...

12 18

Turning acquisition off
by morten＠esol.no 03 Jan '01

03 Jan '01

Hi guys, Does anyone know how to disable acqusition ? That is, with a simple method, and not disabling the Acqusition class, something like self.aq_disabled('attribute') . Thanks. -Morten

8 13

Conflict Errors
by Chris Withers 03 Jan '01

03 Jan '01

Hi, Whenever there's a lot of writes and the occasional read going on, we get the following error: 2000-11-19T16:03:44 INFO(0) Z2 CONFLICT Competing writes at, /aFolder/anObject Traceback (innermost last): File D:\Program Files\Zope\lib\python\ZPublisher\Publish.py, line 175, in publ ish File D:\Program Files\Zope\lib\python\Zope\__init__.py, line 235, in commit File D:\Program Files\Zope\lib\python\ZODB\Transaction.py, line 251, in commit File D:\Program Files\Zope\lib\python\ZODB\Connection.py, line 267, in commit ConflictError: y Can anyone shed any light on: -what this means -how bad it is -how we can make it stop happening cheers, Chris

4 8

ZPatterns Product distribution not showing up as a product?
by jimbo 03 Jan '01

03 Jan '01

Hi, If I try to distribute it and leave it set for "Allow redistribution". Its not showing up in the Zope products directory tree after I untar the 3 files into the file system products directory and restarting Zope. I have a Dataskin based ZClass, 2 Specialist, the default constructor forms. I'm using Zope 2.2.2 on win98 ZPatterns 4.3b2. Is this expected behaviour for a ttw product? It works if I export/import it. -Jimbo

6 7

UNEXPECTED: Acquisition.Explicit may acquire implicitly
by Dieter Maurer 31 Dec '00

31 Dec '00

While trying to understand, what the "bself= self.aq_explicit" in "OFS.DTMLMethod.__call__" should do, I detected an unexpected behaviour: usually, this "bself" acquires implicitly from its container (though not from its context) More precisely: if "bself.aq_self" is itself an implicit acquisition wrapper, the "bself.aq_explicit" acquires implicitly from "bself.aq_self.aq_parent". The following Python module demonstrates the behaviour: ------------------------------------------------------- from Acquisition import Implicit class C(Implicit): pass b= C() b.i= 0 b.d= C() b.h= C() e_bd= b.d.aq_explicit try: e_bd.i print 'e_bd implicitly acquired i' except AttributeError: pass e_bhd= b.h.d.aq_explicit try: e_bhd.i print 'e_bhd implicitly acquired i' except AttributeError: pass ------------------------------------------------------- At first, I thought this were a bug. At second thought, however, it appears to be quite natural, though unexpected: if o is self.__of__(parent), then getattr(o.aq_explicit,k) = getattr(self,k).__of__(o) If "self" is an implicit wrapper itself, then acquisition may be used to look up "k". This implies, that the idiom <dtml-if "_.hasattr(o.aq_explicit,XXXX)"> cannot be used safely to test, whether "o" has attribute XXXX itself (rather than acquired it). We probably should have a standard function for this kind of test. Dieter

1 0

Re: [Zope-dev] DTML Documents == DTML Methods that are anchored?
by Dieter Maurer 30 Dec '00

30 Dec '00

The Doctor What writes: > What are the differences between DTML Documents and Methods > internally? There are too small differences: 1. DTML documents implement the "PropertyManager" interface, i.e. they can have properties other than "id" and "title". 2. DTML documents place themselves on top of the DTML namespace when they are rendered (called), DTML methods do not place themselves on the namespace at all for rendering. The effect is that during name lookup a DTML Document is asked early whether it (or its acquisition ancestors) can satisfy the name request. If it can, you get this object. A DTML Method, on the other hand, would not be asked in a similar situation, as it is not on the namespace stack. This means, name lookup looks through the DTML Method directly onto the method's client, the Method is completely transparent. A DTML Document is only partially transparent, it hides all names that it or its acquisition ancestors define. Only the other names are handled in the same way as would be the case for a DTML method. Dieter

1 0

Updating a ZCatalog when objects in it change their path
by Chris Withers 30 Dec '00

30 Dec '00

Squishdot uses ZCatalog quite heavily. When you move/copy/rename a Squishdot site, all the Paths stored in its catalog become incorrect. Not nice... Darrick experienced this when copying a Squishdot site and then trying to delete a load of articles. He didn't notice the uncatalog errors he was getting when he did this and so reported that articles were still showing up in searches after he'd deleted them. That's because the paths stored didn't change when the site was moved and the delete code in squishdot was trying to delete objects with a path at their new location. Rather than rant about the fact that paths are not unique identifiers for objects in a ZODB (because they change when the objects move, and, as this demonstrates, that's not good!) I thought I'd fix the problem. However, the only way I could find to solve it was to add a manage_afterAdd method to Squishdot Sites which recatalogued all postings. This is a _lot_ more resource intensive than it needs to be, since I don't actually want to recatalog all postings (quite expensive when there are 3000+ of them ;-), I just want to modify the paths that ZCatalog has stored. Is there any way to do this? There probably should be ;-) cheers, Chris

2 2