- Zope-Dev - Zope lists

ugh. bug(?) in ZCatalog.ZopeFindAndApply
by Anthony Baxter 16 Dec '99

16 Dec '99

ooo, this has been an annoying one to track down. When ZCatalog's ZopeFindAndApply is called, it looks at container.aq_base.objectItems() to list the objects in a container, then indexes them. This means that if you're indexing an attribute that's acquired from higher up the chain than the immediate enclosing folder, it won't get picked up. It _will_ when you call manage_catalogReIndex, as it does a resolve_url of the object. This caused much confusion for me, as the Catalog bug I was seeing would be there sometimes and not others, depending on whether a reindex had happened. Two possible fixes here: First is to force a resolve_url before indexing. Second is to index the object in the initial acquisition context (and pass the correct object to the recursive call) Not sure which is the better fix - both work for me. The second is probably cheaper, and "more correct" Note that there's another fix needed for this to work that's in the collector - there's a call to 'find' that should be 'string.find' (line numbers may be off - there's other magic stuff in my local copy.) Can anyone else confirm that this is an appropriate approach? Or is ZopeFindAndApply meant to act this way? ta, Anthony RCS file: /cvs-repository/Zope2/lib/python/Products/ZCatalog/ZCatalog.py,v retrieving revision 1.42 diff -u -r1.42 ZCatalog.py --- ZCatalog.py 1999/11/05 18:58:54 1.42 +++ ZCatalog.py 1999/12/16 07:39:38 @@ -533,7 +559,14 @@ ) ): if apply_func: - apply_func(ob, (apply_path+'/'+p)) + # needed because earlier we retrieved + # container.aq_base.objectItems, otherwise + # we don't see anything acquired from more + # than one acquisition level higher + if REQUEST: + ptmp = apply_path+'/'+p + ob = self.resolve_url(ptmp, REQUEST) + apply_func(ob, (ptmp)) else: add_result((p, ob)) dflag=0 RCS file: /cvs-repository/Zope2/lib/python/Products/ZCatalog/ZCatalog.py,v retrieving revision 1.42 diff -u -r1.42 ZCatalog.py --- ZCatalog.py 1999/11/05 18:58:54 1.42 +++ ZCatalog.py 1999/12/16 07:39:38 @@ -532,14 +558,16 @@ role_match(ob, obj_permission, obj_roles) ) ): + ob_real = getattr(obj, id) if apply_func: - apply_func(ob, (apply_path+'/'+p)) + apply_func(ob_real, (apply_path+'/'+p)) else: - add_result((p, ob)) + add_result((p, ob_real)) dflag=0 if search_sub and hasattr(bs, 'objectItems'): - self.ZopeFindAndApply(ob, obj_ids, obj_metatypes, + ob_real = getattr(obj, id) + self.ZopeFindAndApply(ob_real, obj_ids, obj_metatypes, obj_searchterm, obj_expr, obj_mtime, obj_mspec, obj_permission, obj_roles,

1 0

RE: [Zope-dev] Defining permissions in inherited classes
by Brian Lloyd 16 Dec '99

16 Dec '99

> I've been stuck with this problems for weeks... I posted an earlier > question bug got no replies, so I thought I'd try again. > > I have a product that is used as a mix-in class in several other > products. This product adds a management interface screen and I want > to define permissions to control that screen in this class. So, I do: > > class Publisher(RoleManager): > > __ac_permissions__ = ( > ('Change publishing', ('manage_publish')) > ) > > manage_publish = HTMLFile('publish', globals()) > > In the product that uses this class: > > class Something(Folder, Publisher.Publisher): > > __ac_permissions__ = ( > ('View management screens', ('manage_tabs', > 'manage_main', ....)) > ..... > ) > > manage_options = ( > {'label':'Edit', 'action':'manage_main'}, > {'label':'Publish', 'action':'manage_publish'} > ) > > Now, I think this should work... that's how it's done in > AccessRole.Role.RoleManager - it defines __ac_permissions__ that get > added to the classes that inherit from it. But it doesn't work for > me... the permissions defined in Publisher don't appear anywhere. Any > idea why, or what I'm doing wrong? There is a little bit of non-obvious initialization work that needs to be done to gather the permission information from all the subclasses of an object. This is done by calling the method default__class_init__ (found in the Globals module), passing the class that represents the creatable object. The default__class_init__ method does the correct permission initialization for you. *Note that you must do this for the class of each creatable object your product defines. In your case, you would add to the bottom of your module: import Globals # pass the class of the creatable object # that we are defining so that permissions # are gathered up automatically from the # base classes Globals.default__class_init__(Something) Hope this helps! Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1

Re: [Zope-dev] Re: using ZClasses as DA brains?
by Anthony Baxter 15 Dec '99

15 Dec '99

>>> Jim Fulton wrote > > > Has anyone figured out the necessary magic to get the ZClass-as-brains > > > from the current CVS to work? > > Ah, figured it out. You have to have ZClasses created that don't derive > > from the Persistent base classes - the ZClass interface now includes this. [snip manage_options bug] Another point - it seems like these bare ZClasses don't get Acquisition.Implicit as a base class? This limits their usefulness as traversal methods, surely? Anthony

2 1

Broken products...
by Sascha Matzke 15 Dec '99

15 Dec '99

Hello, I'm using an up-to-date CVS version of zope for development of my python based product. If I broke one of my products in an earlier release, then there would be a broken box in the Products listing. Now this seems to be gone... (and I miss it, because it provided me a traceback of what went wrong) Now the only hint that I've broke a product is that the provided meta_types are missing in the "Available Objects" selection... How could I now get the traceback of a broken product ?? Sascha -- .-> Sascha Matzke - sascha(a)bespin.de - http://www.bespin.de -. | Keine Macht fuer niemand... | | Ton Steine Scherben | `-- On this earth for 24 years, 63 days <----------------'

1 1

Inheritance isn't working, or Mystery of the Missing Doc Strings
by itamars＠ibm.net 15 Dec '99

15 Dec '99

Food ZClass inherits from ZWorkflow ZClass, and from a python base class FoodBase that inherits from OFS.ObjectManager.ObjectManager. So, calls to objectItems should be "sent" to FoodBase, who then "sends" them to ObjectManager. Instead, I get an error saying "Missing doc string"!!! Just to explain fully, ZWorkflow inherits from python class Workflow which in turn inherits from CatalogAware. None of the above define objectItems anywhere. What's going here? And why do the things always happen when I'm on a deadline?

3 2

Persistence of objects created by external methods
by Jason Abate 15 Dec '99

15 Dec '99

I have a fairly sizable application built on top of Zope that is based on a bunch of my own Python code. This was started about 9 months ago, so it probably doesn't use the latest Zope-isms, but it works for the most part, except that I now have a problem with persistence. Here's the setup I have: I have a Python class called SiteControl, and an external method, taken from some early Zope documentation, which creates an instance of this class and stores it in the Zope database: from Shared.SiteControl.SiteControl import SiteControl def CreateSiteControl(self): "Add a SiteControl instance" setattr(self, 'SiteControl', SiteControl()) return "Created SiteControl instance" This works fine - I can access the SiteControl object and all of its methods from a browser. The problem is that the SiteControl object contains two dictionaries which store a list of users currently logged into the system. In the __init__() method, these are initialized to be empty dictionaries. What I would like is for these dictionaries to be persistent. However, whenever the server is restarted (which seems to happen fairly frequently. I'm still tracking this down, and guess that it is a problem with my code rather than Zope), the dictionaries are reset to be empty, which requires users to login again. Is it possible to have these objects that are in the SiteControl object persistently stored in the Zope database? I've tried to subclass SiteControl from Persistent, but it seems to be just a document string and no class. Am I missing something here? Is there some other way to make these subobjects persistent? Thanks for any help, --jason -- Jason Abate Hostway Corporation jason(a)hostway.com

1 0

Re: using ZClasses as DA brains?
by Anthony Baxter 15 Dec '99

15 Dec '99

>>> Anthony Baxter wrote > Has anyone figured out the necessary magic to get the ZClass-as-brains > from the current CVS to work? > > It seems like the 'advanced' tab needs 'manage_product_zclass_info' > which is in Shared/DC/ZRDB/DA.py - but I'm stuffed if I can figure > out how this is meant to work... Ah, figured it out. You have to have ZClasses created that don't derive from the Persistent base classes - the ZClass interface now includes this. Unfortunately the fix to ZClass.py:1.37 to copy manage_options from the base class fails if you create a ZClass that derives from nothing at all. I wrapped the copy operation in an if zope_object: test (not sure that this is the best approach, a better one might be to test for manage_options being there at all) and it's happier... Anthony

2 1

RE: [Zope-dev] Object ownership
by Michel Pelletier 15 Dec '99

15 Dec '99

> -----Original Message----- > From: Toby Dickenson [mailto:tdickenson@geminidataloggers.com] > Sent: Wednesday, December 15, 1999 4:51 AM > To: zope-dev(a)zope.org > Subject: RE: [Zope-dev] Object ownership > > > > is there a method that i could use to find out an object's owner? > > I have this in my Intranet standard_html_header. (Its also a > good example of > dtml gone wild) > > > <dtml-if get_local_roles> > <dtml-in get_local_roles> > <dtml-if "'Owner' in _['sequence-item'] and > _['sequence-key'] != > 'za'"> > <dtml-if one_owner_already_mentioned> > ; > <dtml-else> > This page is maintained by > <dtml-call > "REQUEST.set('one_owner_already_mentioned','yes')"> > </dtml-if> > <a href="mailto:<dtml-var sequence-key>"><dtml-var > sequence-key></a> > </dtml-if> > </dtml-in> > <dtml-if one_owner_already_mentioned> > </dtml-if> > </dtml-if> There is an Owner method for cataloging purposes for catalog aware objects, or there was at one point. I have it in my bag for attaching to portal objects when we move into content managment. I think something like this should be part of the framework, though. -Michel

1 0

RE: [Zope-dev] Re: using ZClasses as DA brains?
by Michel Pelletier 15 Dec '99

15 Dec '99

> -----Original Message----- > From: Anthony Baxter [mailto:anthony@interlink.com.au] > Sent: Tuesday, December 14, 1999 9:00 PM > Cc: zope-dev(a)zope.org > Subject: [Zope-dev] Re: using ZClasses as DA brains? > > > >>> Anthony Baxter wrote > > Has anyone figured out the necessary magic to get the > ZClass-as-brains > > from the current CVS to work? > > > > It seems like the 'advanced' tab needs 'manage_product_zclass_info' > > which is in Shared/DC/ZRDB/DA.py - but I'm stuffed if I can figure > > out how this is meant to work... > > Ah, figured it out. You have to have ZClasses created that > don't derive > from the Persistent base classes - the ZClass interface now > includes this. > > Unfortunately the fix to ZClass.py:1.37 to copy > manage_options from the > base class fails if you create a ZClass that derives from > nothing at all. > I wrapped the copy operation in an if zope_object: test (not > sure that this > is the best approach, a better one might be to test for manage_options > being there at all) and it's happier... Can we review your diff? -Michel

1 0

RE: [Zope-dev] ZODB DA?
by Michel Pelletier 15 Dec '99

15 Dec '99

> -----Original Message----- > From: Jim Fulton [mailto:jim@digicool.com] > > The ZODB has a well-defined "storage interface" that should > make implementation of a reiserfs- (or just an fs-) > based storage reasonably straightforward, although getting > transactional sematics right might be a tad tricky. When Jim says 'tricky' it means your brain could explode. -Michel

1 0