- Zope-Dev - Zope lists

Python Scripts update
by Evan Simpson 04 Jan '01

04 Jan '01

Python Scripts have gone through a fair number of changes and bugfixes recently. They should now work properly as methods of ZClasses. When you download the source of a Python Script, the title, parameter list, and bindings are added to the source in the form of specially formatted comments. If source with these comments is uploaded or pasted into a Python Script, it will properly set the properties mentioned in the comment block. The default bindings have been changed to be more sensible. If you want to give Python Scripts a try, you can go to http://ps.4-am.com:9000/ , pick a password, and you'll get your own private area in a trunk CVS checkout of Zope in which to play. I promised examples when I first announced this site, and haven't gotten around to writing any. If you have created a script or set of objects on the demo site that you would like to share as an example, please mail me the URL. Cheers, Evan @ digicool & 4-am

1 0

ZPatterns; possible bug?
by Steve Alexander 04 Jan '01

04 Jan '01

I have a specialist "Instructors". It holds a rack, containing DataSkin-derived ZClasses of meta-type "Instructor". The Instructor class has a DataSkin Attribute propertysheet called "Basic", and this has properties for forename, surname, address, areas. I have some skinscript in the Instructors specialist: WITH SELF COMPUTE name='%s %s' % (forename, surname), areas_comma_sep=_.string.join(areas, ','), address_lines=_.string.join(address, '\n'), address_comma_sep=_.string.join(address, (', ')) WITH SELF COMPUTE __roles__=_.None # XXX publicly visible!! Nutter!! # change __roles__ to ('Operator',) later. This works fine. The __roles__ bit is a hack to make Zope 2.3 ZCatalog play nicely with the Specialist and __bobo_traverse__. I have some other skinscript that keeps an instructors index in a ZCatalog inside Instructors. WHEN OBJECT ADDED CALL Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/')) WHEN OBJECT DELETED CALL Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')) WHEN OBJECT CHANGED CALL Catalog.uncatalog_object(_.string.join(self.getPhysicalPath(),'/')), Catalog.catalog_object(self, _.string.join(self.getPhysicalPath(),'/')) This worked fine. When I changed the first skinscript to make one WITH SELF statement, I got some strange inconsistencies: WITH SELF COMPUTE name='%s %s' % (forename, surname), areas_comma_sep=_.string.join(areas, ','), address_lines=_.string.join(address, '\n'), address_comma_sep=_.string.join(address, (', ')), __roles__=_.None On changing an instructor's properties using manage_changeProperties on its propertysheet, I'd see the change in the instructor. However, the ZCatalog metadata would always have the most recent value for "surname", but the last value for "name". Changing the skinscript back to using two statements makes cataloging function normally again. I could tell when the catalog was doing by instrumenting the recordify method of Catalog.py: def recordify(self, object): """ turns an object into a record tuple """ print "recordify %s" % (object) record = [] # the unique id is allways the first element for x in self.names: try: attr = getattr(object, x) if(callable(attr)): attr = attr() except: attr = MV print " appending %s:%s" % (x, attr) record.append(attr) return tuple(record) A typical (wrong) debug output would be: recordify <Instructor instance at 86c16b0> appending id:instructor-977678608 appending meta_type:Instructor appending bobobase_modification_time:2001/01/04 17:26:01.35408 GMT appending name:Bob Collins8 appending surname:Collins9 appending areas_comma_sep:M12 This is after changing the surname of the instructor from "Collins8" to "Collins9". The cause of the problem? I don't know. Maybe I'm doing something silly. I think what is happening in the broken example is that when the zope security machinery asks for __roles__, name is also computed. The machinery must request __roles__ before changing anything. After that, surname gets changed. However, changing "surname" only invalidates "surname" in the cache; not anything that is computed using surname. At the end of the transaction, when the triggers are called, name is already in the dataskin's attribute cache, so it does not get recomputed. In the working example, when __roles__ is requested, it is in a different skinscript statement, so it does not cause "name" to be computed. Thus, "name" can be computed freshly after "surname" is set. Is this behaviour intended, is it a bug, or is it an unimplemented feature? Thanks. Oh, almost forgot: ZPatterns-0-4-3b2 -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net I

2 1

ghost product
by Tim McLaughlin 04 Jan '01

04 Jan '01

In fact (to clarify my preceding problem), when I removed the product folder, Zope still shows the product and error after restarting. Am I being stupid? I must be missing something.... Thanks

2 1

Product dev
by Tim McLaughlin 04 Jan '01

04 Jan '01

I'm building a Product in Python and seem to be having some issues with the new registerClass method of Product registering. If I build it all fine as noted in Shane's recent HowTo, the product does not show up in the control panel. Then after much other chasing, I make a purposeful syntax error in the code, and the Product shows up to reflect its brokenness and shows me the syntax error. Then when I try to fix the error, and do a restart, the error still shows as if I had not changed the code. I checked _many, many_ times, and now the code is different, but Zope seems not to recognize the changed code in spite of my deletion of the pyc files. TYA, Tim

1 0

Re: [Zope-dev] case insensitive sorts
by Tres Seaver 04 Jan '01

04 Jan '01

Chris Withers <chrisw(a)nipltd.com> wrote: > Andy McKay wrote: > > > > They want information fast and most users expect case insensitive sorts. Its > > simpler and easy. I think having the ignore_case option for a -tree and -in > > helps Zope by increasing the ease of development and friendliness to the > > user. > > And my point was that this is so universally true that the _pthyon_ sort > function (which is at fault here) should be fixed :-) Python's sort already allows you to pass an alternate comparison function:: [/var/home/tres] $ python Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> foo = [ 'z', 'y', 'x' ] >>> foo.sort() >>> foo ['x', 'y', 'z'] >>> foo.sort( lambda x, y: cmp(y,x) ) >>> foo ['z', 'y', 'x'] I believe Andy's patch makes use of this feature. You are missing a couple of points if you *require* a case-insensitive sort: * collation (which letters belong together) is highly locale sensitive (e.g., does a-accent-grave sort with a? etc.) * Should strings which differ only in case be equal (*NOT*!) Tres. -- =============================================================== Tres Seaver tseaver(a)digicool.com Digital Creations "Zope Dealers" http://www.zope.org

2 1

WIN2K batch problem
by Robin Becker 04 Jan '01

04 Jan '01

I'm trying to run Zope 2.2.2 under win2000 in a batch file. I'm just watching error messages and prints. I find that when zope has written a page to the cmd.exe window it locks further prints from python until I hit a key in the window and then it releases another page full. Is there a Win NT/2K guru who knows about such things and how to prevent this? -- Robin Becker

1 0

Re: [Zope-dev] Objects with multiple parents and storageflexibility, ZPatterns?
by Chris Withers 04 Jan '01

04 Jan '01

"Phillip J. Eby" wrote: > > You can't really "nest" DataSkins inside each other in a rack, and you > really don't want to, anyway. I kindof agree, I guess nesting doesn't mean a lot in RDBMS terms? ;-) > But there's nothing that says you can't > create a DataSkin subclass whose __bobo_traverse__ looks up related > objects. Hurm, could something similar be doen so a DataSkin could implement the objectmanager interface? > You just can't "really" store the DataSkins inside each other. I don't want to, I only want it to appear to Zope, ZPublisher and the Management Interface as if that was the case. The only difference being that 'objects' can appear under more than one parent. > Note that if your __bobo_traverse__ uses a specialist "getXforY()" call, > you can "store" objects from different databases (racks) "inside" each > other. :) I like the sound of that :-) Well, thanks for the help so far, I'm going to have to bite the bullet and start implementing tomorrow :-S cheers, Chris

1 0

How to confuse the publishing process
by Chris Withers 04 Jan '01

04 Jan '01

If you go to a URL that ends in a folder, you get the index_html in that folder, right? Well, yes and no... If you go to: http://server.com/folder1/folder2/folder1 ...where folder1 is a folder in your Zope's root, folder2 is contained in folder1, but doesn't itself contain a folder1 (so the last folder1 in the url is also the first one, just acquired), Zope returns the following: <html><head> <base href="http://localhost:8080/testnav/normaltest/testnav/"> </head> <body> <Folder instance at 014B3D80> </body> </html> So, what's going on here? why no index_html rendering? cheers, Chris

2 4

Frozen Zope?
by BS 04 Jan '01

04 Jan '01

Has anyone tried to use the "Freeze" utility on Zope? How about Gordon McMillian's "Install" application to make a self-contained Python-Zope executable for Win32? My goal is to create a very easy install of Zope that consists of one or two files. For some of my clients this seems less intimidating on their machines (they would rather not see the "source code", just an executable). Do you think this is possible? Thanks

2 1

Re: [Zope-dev] Re: Starting ZServer
by Dieter Maurer 03 Jan '01

03 Jan '01

me_in_apache(a)dacafe.com writes: > My Zserver has started at 8080 but the manage.dtml is not > accessible from the browser either as localhost or with the host name. > Please suggest me an answer the problem ASAP. You are using: http://localhost:8080/manage do you? You must not use "manage.dtml"! Dieter

1 0