December 1999 - Zope-Dev

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

FCGIServer.py broken again?
by news-list.zope.dev＠innominate.de 15 Dec '99

15 Dec '99

hi, i just wanted to set up a zope server on another machine: - apache on port 80 + mod_fastcgi-snapshot - zope 2.1.1 using fcgi via socket i'm running the very same config on another machine without any problems but here i get tracebacks after the first request for a zope page: -------------------------------------------------- Traceback (innermost last): File "/usr/local/lib/Zope-2.1.1-src/z2.py", line 583, in ? asyncore.loop() File "/usr/local/lib/Zope-2.1.1-src/ZServer/medusa/asyncore.py", line 107, in loop poll_fun (timeout) File "/usr/local/lib/Zope-2.1.1-src/ZServer/medusa/asyncore.py", line 66, in poll x.handle_error() File "/usr/local/lib/Zope-2.1.1-src/ZServer/medusa/asyncore.py", line 321, in handle_error self.close() File "/usr/local/lib/zope/ZServer/FCGIServer.py", line 573, in close p.more() # free up resources held by producer File "/usr/local/lib/Zope-2.1.1-src/ZServer/Producers.py", line 108, in more getattr(self.logger, self.method)(self.bytes) File "/usr/local/lib/zope/ZServer/FCGIServer.py", line 496, in log_request time.gmtime(time.time()) TypeError: illegal argument type for built-in operation -------------------------------------------------- the code that seems to be causing the traceback is this: self.server.logger.log ( self.addr[0], '%d - - [%s] "%s %s" %d' % ( self.addr[1], time.strftime ( '%d/%b/%Y:%H:%M:%S ', time.gmtime(time.time()) ) + tz_for_log, method, path, bytes ) ) when i replace the %d for self.addr[1] to %s it seems to work but then the logging looks ugly... anybody with the same problem or maybe even a solution...?! the strange thing is that the same config is working on another machine so i guess maybe some external influence (apache, proxy) is causing the problem... thilo -- mezger(a)innominate.de innominate AG networking people fon: +49.30.308806-11 fax: -77 web: http://innominate.de pgp: /pgp/tm

1 0