- Zope-Dev - Zope lists

2 ZEO Wikis.
by Chris McDonough 19 Jul '00

19 Jul '00

In trying to find the "Quorum Based Replication" stuff I've found that we have two ZEO wikis. http://www.zope.org/Products/ZEO/Wiki/FrontPage http://www.zope.org/Wikis/ZEO/FrontPage Bleah. Chris McDonough Digital Creations Publishers of Zope - http://www.zope.org

1 0

Intializing the objects formerly-known-as-RackMountables
by Itamar Shtull-Trauring 19 Jul '00

19 Jul '00

I need to do initialize some properties of new instances of a DataSkin subclass - ASPAccount. However, I can't put this in __init__ since the object hasn't been stored at that point. Doing self.__dict__['name'] = 'Rincewind' seems kinda ugly. Maybe newItem should by default call a function on newly created objects, say __init? I don't want to have to subclass Specialist (or in my case, LoginManager) each time I want to this, since it's a *very* common action. For example, *** Specialists.py.orig Wed Jul 19 12:37:32 2000 --- Specialists.py Wed Jul 19 12:38:18 2000 *************** *** 37,43 **** def newItem(self, key=None): """Create a new item""" # Default use first rack ! return self.rackList[0].__of__(self).newItem(key) def manage_refreshPlugIns(self, REQUEST=None): """Update plugin registries""" --- 37,46 ---- def newItem(self, key=None): """Create a new item""" # Default use first rack ! obj = self.rackList[0].__of__(self).newItem(key) ! if hasattr(obj, '__init'): ! obj.__init() ! return obj def manage_refreshPlugIns(self, REQUEST=None): """Update plugin registries"""

2 3

HTTP user agent?
by Brian Takashi Hooper 19 Jul '00

19 Jul '00

Hi Zopistas, For anyone that might know: Is there a particular reason that the User-Agent header is not part of the request data that ZServer sends in the environment to ZPublisher? It looks like the user agent can also be provided to Zope's request object just by adding a line for 'user-agent' to ZServer.HTTPServer.header2env: header2env={'content-length' : 'CONTENT_LENGTH', 'content-type' : 'CONTENT_TYPE', 'connection' : 'CONNECTION_TYPE', 'user-agent' : 'HTTP_USER_AGENT' } Is there a particular reason this is not done? --Brian Hooper Digital Garage, Inc. Tokyo, Japan

2 1

One more bug
by mike 19 Jul '00

19 Jul '00

Fix for www/storageForm.dtml $ diff storageForm.dtml.orig storageForm.dtml 7c7 < <FORM METHOD="POST" ACTION="manage_setStorage"> --- > <FORM METHOD="POST" ACTION="."> 56c56 < <br><INPUT TYPE="SUBMIT" value=" Change Storage Settings"> --- > <br><INPUT TYPE="SUBMIT" name="manage_setStorage:method" value=" Change Storage Settings">

3 3

several permissions for the same method
by Jephte CLAIN 19 Jul '00

19 Jul '00

Hello, is it possible for a single method, under Zope 2.1.6, to have several permissions? ie __ac_permission__ = ( ('edit my data', 'edit_data'), ('edit others\'s data', 'edit_data'), ) I have the scenario where a user can edit *its* data but not other users's data, unless he has a special role. however, the method used to edit one's data is the same. So I make sure inside the edit_data method that the user has the adequate permissions if he tries to edit another one's data. this does not work. indeed, lib/python/AccessControl/Permission.py reads: # Attribute names which appear in a # permission may not appear in any other permission defined # by the object. thanks in advance for any advices. regards, jephte.clain(a)univ-reunion.fr

2 1

Re: [Zope-dev] More comments on ZPatterns
by Steve Spicklemire 18 Jul '00

18 Jul '00

>>>>> "pje" == Phillip J Eby <pje(a)telecommunity.com> writes: >> a (default) rack of TableInfo objects. >> >> Now... some of the Tableinfo properties, and some of the View >> properties are *really* in MySQL. I figured out, from the mail >> list and the source code, that I can create a Generic attribute >> provider in the rack that can get attributes from an SQL >> database for my DataSkin descendents using the 'source >> expression' and 'target expression' business. pje> Congratulations, you found the top secret documentation. :) That's what I love about working with ZPatterns. You get to play all sorts of "Roles" as a developer... part "James Bond", part "Hercule Poirot", part "Bumbling Imbecile". ;-) I've heard that it's "Roles before Objects" but I had no idea it would be like this! Here's one I've been feeling kinda stupid about: >Now, "SkyDiver ... *used as*" means we should: > > 1. subclass (not a good choice) > 2. implement interface > 2.1. by copying and pasting methods code (or whole methoids) > 2.2. by proxiyng (SkyDiver has a references to actual Customer > and ResourceUser) > 2.3. by transmitting messages to SkyDiverSpecialist which will pass > unhandled messages to CustomerSpecialist and > ResourceUserSpecialist (this is a variant of 2.2. case) > >The 2.3. case means we should use objects without types (identity >markers). pje> None of the above. SkyDiver should inherit from a Party base class. For pje> Customer and ResourceUser behavior, one adds propertysheets whose class is pje> provided by the respective frameworks. This is extension through pje> *composition*, rather than inheritance. It is similar to the COM approach, pje> where you can ask an object to give you a pointer to an interface. In this pje> approach, you ask for a propertysheet that provides the interface. "One adds propertysheets" is much easier said than done... IMHO. The only way I've seen to add propertysheets to objects is to call manage_addPropertySheet on individual instances... as described in this earlier email: pje> pje> This isn't exactly code, but... pje> pje> Set up a LoginManager with a GenericUserSource, and set up the GUS to have pje> users. Make sure that the GUS has a "Persistent Sheet Provider" on the pje> "Sheet Providers" tab. Then go to: pje> pje> /acl_users/someuser/propertysheets/manage_addPropertySheet?id=sheetname&ns= pje> pje> You should get a screen that says "OK". pje> pje> Then go to: pje> pje> /acl_users/someuser/propertysheets/sheetname/manage pje> pje> And you should see a propertysheet editor for your new sheet. pje> (Unfortunately, it won't let you edit anything unless your user class is pje> based on PropertyManager, due to an oversight in ZPatterns 0.3.0; the pje> VirtualSheets class needs "def propertyLabel(self,id): return id" to work pje> with the default Zope UI for a non-ZClass property sheet.) pje> pje> Or go to: pje> pje> /acl_users/someuser/propertysheets/manage pje> pje> And you should see your new propertysheet listed on the sheets management pje> interface (which is somewhat broken, but that's because the basic one in pje> Zope is, it's not ZPatterns' fault. ;) ) pje> pje> Anyway, this is all very primitive but should get better in later versions. pje> 0.4.0 fixes the 0.3.0 and either it or 0.5.0 will replace the broken pje> propertysheets/manage screen with one that will let you add/edit/delete pje> sheets properly. I just want to make sure I understand... is the intention that property management needs to be done on each instance separately? So if I add a new property to one of my property sheets, I need to somehow update the propertysheets of each of the instances? Also.... if I need to create propertysheets for each instance... where should that be done? I suppose it makes sense to put that in the Specialist that handles the object that gets the properties?...no? thanks, -steve

5 13

RE: [Zope-dev] Request for amplification on new Product permissio ns API.
by Brian Lloyd 18 Jul '00

18 Jul '00

> So, what do I need to do to allow controlled access to this object? > I understand that Shopper, inheriting from SimpleItem, already has > the access to unprotected subobjects flag. And I'd rather protect > the object correctly, anyway <grin>. I tried adding an ac_permissions > structure to the class, giving View permission to the attribute > that is throwing the unauthorized error, but that doesn't seem to > have changed the behavior. Are you calling: Globals.default__class_init__(MyBasketClass) on your Basket class? This is (poorly documented but) necessary for permissions declared in __ac_permissions__ to be correctly initialized. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

3 2

Racks and Specialists Simplified
by Shane Hathaway 18 Jul '00

18 Jul '00

Phillip, I believe I have come to understand the basics of ZPatterns and would like to be sure I understand correctly, as well as help others understand also. I like to think of a specialist as a filing clerk. A manager comes to the clerk asking for an employee's dental records. Because of the way the company filing system was set up, however, the dental records aren't kept on a single slip of paper. The clerk has to compile the information from the employee's medical and insurance information. The manager doesn't care where the information is coming from, but needs the information on a standard dental record form. So the clerk compiles it and gives the manager the information on the correct form. In this example, the manager is the "application framework", the file cabinets are "racks", and once again the clerk is the "specialist". An application framework generally looks in database tables for objects of a specific type. The types of objects may include users, invoices, grades, etc. A rack is an abstract database table. The data can be stored in ZODB or in some other way, but the point is that a rack is a container for a list of objects of the same type. The basic functionality of a rack can be duplicated by creating a folder and populating it with methods that access a database table, then calling the methods of that folder rather than accessing the database directly. A specialist essentially provides views, or "sheets", of data from one or more racks. The information on a sheet is compiled from one or more sources and contains the precise information required of the application framework. If used correctly, the RIPP model makes integration of multiple Zope-based application frameworks relatively straightforward. This means that, for example, a Zope calendar product could gather date information from a Zope logging product, which of course knows nothing about calendars. Now, the above is what ZPatterns has been claiming all along. But what does it really mean? Well, if you think about it for a moment, the place where people usually want to integrate applications is at the database tables. For example, a database of users contains nothing more than name, login, and password. But what if we want to integrate a user authentication application with a billing application? The billing application looks for a different set of fields, such as account balance, payment due date, etc. and is not interested in the user's password. The obvious approach is to add more fields to the database table or create another table and join the two. A more flexible approach, however, is to abstract out the database table access, making the storage details irrelevant to the application. This has always been possible, but ZPatterns makes it easier. The other concepts in ZPatterns expand upon this model. I am still working on grasping them. ZPatterns also provides the "Plugins" architecture. Racks and specialists are derived from the plugins classes. I see plugins as being a concept that could be used by product authors who don't have a use for racks and specialists. I wonder whether plugins ought to be made a part of standard Zope. Shane

6 10

Traceback
by jpenny＠universal-fasteners.com 18 Jul '00

18 Jul '00

How hard would it be to add more of the called URL to the traceback? Background: I have been developing relatively baroque SQL sites for internal use and find that when I am making changes to facilitate re-use higher up in the hierarchy, it can be relatively difficult to find out what failed. For example, I get this traceback: Traceback (innermost last): File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ElementWithAttributes) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/OFS/DTMLDocument.py, line 170, in __call__ (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/DocumentTemplate/DT_String.py, line 502, in __call__ (Object: index_html) File /home/jpenny/zope/Zope-2.2.0b4-src/lib/python/DocumentTemplate/DT_Util.py, line 337, in eval (Object: product_number) (Info: product_number) File <string>, line 0, in ? NameError: (see above) Great, I know that I have not put product_number in as a cookie or a hidden value, and it could not be found by acquisition. It failed in rendering index_html. But there are 5 index_html's it could have failed in. How hard would it be to change the error message to say: Traceback (innermost last): Exception raised while constructing http:.... . . . Jim

1 0

RE: [Zope-dev] The Application object
by Chris McDonough 18 Jul '00

18 Jul '00

> Sorry I wasn't clear enough. The Singleton is a design > pattern from the > Gang of Four book that fits this situation well. It is a > class that is > meant to control access to the one and only instance of a global > variable. I was just using that as a frame of reference, > though; Zope has > no such class for the Application object, or I wouldn't be > writing this > message. Oh, ok, sorry, hard to tell intent from actual code. :-) > > I just need some way of getting at the one and only > Application object at > run-time. Something like: > > from Globals import app > myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo') > ... > > Given a reference to an object in the ZODB, I can do this via: > > app = self.getPhysicalRoot() > myOb = app.Control_Panel.Products.MyProduct.MyZClass('foo') > > But, this does not work from methods like __init__, or > __setstate__, where > we do not have a physical location in the ZODB, yet. Ah, I see the problem. I'm afraid I don't know the answer. I generally use the manage_afterAdd and manage_beforeDelete methods to do things like this. I suppose you could pass the root object into the constructor. __setstate__... well. Err... Anybody else?

4 7