- Zope-Dev - Zope lists

Catching "extra path"
by Ian Beatty 09 Mar '04

09 Mar '04

Hi again. I'm chipping away at the problem I asked about earlier ("Product Access to Files") -- or perhaps just beating my head against it -- and I've got another question. If I'm writing a Python script within the ZMI, any URL that resolves to my script will invoke the script, even if the URL has "extra" stuff appended: http://host/folder/script/a/b/c will invoke a script at /folder/script. Furthermore, I can get at the "a/b/c" part from within the script by accessing 'traverse_subpath'. The question is, how can I do this from within a Python-based product? Calling http://host/folder/object/method/a/b/c fails to invoke the method 'method' on my custom object 'object'. Instead, I get a "Cannot locate object" page. It's hard to believe there's something I can do with a ZMI Python script that I can't do in a Python product... Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty beatty(a)physics.umass.edu Physics Education Research Group voice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-4525 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --

3 2

Product directory?
by Ian Beatty 09 Mar '04

09 Mar '04

Greetings again. This has to be an easy one. >From within my Python-based product's code, how do I get access to the product's directory on the filesystem? os.getcwd() seems to provide the working directory of the shell used to launch Zope, at least when running in debug mode. I've tried ferreting it out from the source to DTMLFile and etc., but I can't trace it. Thanks, ..Ian -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- Dr. Ian Beatty beatty(a)physics.umass.edu Physics Education Research Group voice: 413.545.9483 Department of Physics fax: 413.545.4884 Univ. of Massachusetts AIM: (available upon request) Amherst, MA 01003-4525 USA http://umperg.physics.umass.edu/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --

4 4

zope products and folders
by Stephen Rudd BIOINF 09 Mar '04

09 Mar '04

Please excuse me if this subject is off-topic - there seem to be no zope lists for the syntax of zope products! I am writing a zope product for the representation of biological data in a user aware context. I have a working product that satisfies my primary needs - but I would like to improve a little before releasing. Could someone explain (or point me to resources) how to turn a product into a "folder" like object so that I can bind images, DTML or python scripts directly into the product - I am stumped and cannot find any explanation for this. I have looked at the code from Squishdot etc - and find that this has something to do with "manage_main" - I cannot progress beyond this. Thanks Stephen Dr Stephen Rudd Turku Centre for Biotechnology Finland

2 1

Specify a domain and leave the password for a user blank
by Juan Javier Carrera Obrero 09 Mar '04

09 Mar '04

Hi, In Zope 2.4 or older versions when a user is created, if you specify a domain and leave the password for a user blank, then anyone from the permitted domains automatically gets the user's roles without having to log in. However, it is not possible in Zope 2.7. I have created a user specifying a domain and leave the password for this user blank, and although I am in the domain, I have to log in. Anybody help me about it ? How can I create a user, specifying a domain, and if the user is in the domain does not have to log in? Thanks.- ----- Original Message ----- From: <zope-dev-request(a)zope.org> To: <zope-dev(a)zope.org> Sent: Tuesday, March 09, 2004 12:36 PM Subject: Zope-Dev Digest, Vol 8, Issue 15 > Send Zope-Dev mailing list submissions to > zope-dev(a)zope.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.zope.org/mailman/listinfo/zope-dev > or, via email, send a message with subject or body 'help' to > zope-dev-request(a)zope.org > > You can reach the person managing the list at > zope-dev-owner(a)zope.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Zope-Dev digest..." > > > Today's Topics: > > 1. Re: Re: Unexpected Behaviour iterating over catalog search... > (Dieter Maurer) > 2. Zopeservice and sitecustomize (Sake) > 3. Re: Zopeservice and sitecustomize (Chris McDonough) > 4. RE: Zopeservice and sitecustomize (Tim Peters) > 5. RE: Zopeservice and sitecustomize (Tim Peters) > 6. Re: Re: Unexpected Behaviour iterating over catalog search... > (Chris Withers) > 7. Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope > 2.X BIG Session problems - blocker - our site dies - need help of > experience Zope developer, please) (Alex V. Koval) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 8 Mar 2004 20:05:04 +0100 > From: Dieter Maurer <dieter(a)handshake.de> > Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over > catalog search... > To: Jean Jordaan <jean(a)upfrontsystems.co.za> > Cc: zope-dev(a)zope.org > Message-ID: <16460.50144.170406.811279(a)gargle.gargle.HOWL> > Content-Type: text/plain; charset=us-ascii > > Jean Jordaan wrote at 2004-3-8 16:33 +0200: > >>> Surely the thing returned by a Catalog search should be immutable? > >> > >> Nope, it is "lazy"; immutability would require "realizing" it first, > >> which would be prohibitively expensive in many cases. > > > >Yes .. thing is, wrapping with list() or tuple() will therefore > >also be prohibitive in those cases, > > When you want to uncatalog everything, "tuple"ing the result should > not be a problem. > > Otherwise, a standard approach is to remember the objects you > want to delete in a standard list and iterate over this list > in a separate loop (outside the first one). > > -- > Dieter > > > > ------------------------------ > > Message: 2 > Date: Tue, 09 Mar 2004 08:54:54 +0700 > From: Sake <sakesun(a)boonthavorn.com> > Subject: [Zope-dev] Zopeservice and sitecustomize > To: zope-dev(a)zope.org > Message-ID: <404D23EE.1080702(a)boonthavorn.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > I have Zope and Activestate Python installed together in the same win-xp > machine. Everything works fine until I've learned that I can put > "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my > native language coding. Since I do that, my Zope 2.7.0 service can no > longer start. I can start it manually from "runzope.bat", but it never > start through the windows system service. A full day investigation > reveal that the trouble cause by the missing of the > '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". > The "runzope.bat" set that up before then execution of > "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on > the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up > the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py > > """ Add Zope packages in Windows binary distro to sys.path automagically """ > import sys > import os > try: > sp = __file__ > except: > sp = None > if sp: > dn = os.path.dirname > swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') > if os.path.exists(swhome): > sys.path.insert(0, swhome) > > Unluckily, this sitecustomize.py is now masked with my sitecustomize.py > inside Activestate's site-package directory, which actually get loaded > by Zope via the Python registry load path > (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead > of the expected one. > > I don't think setting up PYTHONPATH inside sitecustomize.py is a good > idea. Better keep this mechanism for site specific problems. I'd rather > insert a line into zopeservice.py like this. > > import os.path > from os.path import dirname as dn > import sys > > # these are replacements from mkzopeinstance > PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' > SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' > INSTANCE_HOME = r'C:\Zope-MIB' > ZOPE_HOME = r'C:\Zope-2.7.0' > > ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME > CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') > PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME > > sys.path.insert(0, SOFTWARE_HOME) > os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line > > from nt_svcutils.service import Service > > servicename = 'Zope_%s' % str(hash(INSTANCE_HOME)) > > class InstanceService(Service): > start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) > _svc_name_ = servicename > _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME > _exe_name_ = PYTHONSERVICE_EXE > > if __name__ == '__main__': > import win32serviceutil > win32serviceutil.HandleCommandLine(InstanceService) > > > > This is much more palatable in my opinion. > > > > > ------------------------------ > > Message: 3 > Date: Mon, 08 Mar 2004 22:14:10 -0500 > From: Chris McDonough <chrism(a)plope.com> > Subject: Re: [Zope-dev] Zopeservice and sitecustomize > To: Sake <sakesun(a)boonthavorn.com> > Cc: zope-dev(a)zope.org > Message-ID: <1078802050.12387.38.camel@athlon> > Content-Type: text/plain > > On Mon, 2004-03-08 at 20:54, Sake wrote: > > > Everything works fine until I've learned that I can put > > "sys.setdefaultencoding('cp874')" into sitecustomize.py > > I assume you created a new sitecustomize.py to hold this in your > activestate Python's library directory, then? > > > I can start it manually from "runzope.bat", but it never > > start through the windows system service. A full day investigation > > reveal that the trouble cause by the missing of the > > '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". > > The "runzope.bat" set that up before then execution of > > "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on > > the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up > > the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py > > This was put here because in my tests I could not make Python recognize > the "right" set of paths by setting an environment variable in the > zopeservice script. > > As you probably noticed, Zope does not run in the same Python > interpreter instance as the one that zopeservice.py runs under. > zopeservice.py instead turns around and invokes another Python > interpreter to actually do the running of Zope itself (that's what > "start_cmd" is set for). Worse, the windows Service code actually > doesn't invoke zopeservice.py directly; it is run as a side effect of > the PythonService.exe executable being run. Setting a PYTHONPATH via > os.environ in zopeservice was not doing the trick for me (at least on > Win2K); why was unclear, although I think it was because the environment > being modified by setting os.environ within zopeservice is not carried > over to child processes. A batch file couldn't be used as the target > for the service because the Windows shell doesn't keep track of child > processes in the same way UNIX does: child processes aren't killed when > their parents are and there is no way to 'exec' another command from a > Windows batch file. > > > Unluckily, this sitecustomize.py is now masked with my sitecustomize.py > > inside Activestate's site-package directory, which actually get loaded > > by Zope via the Python registry load path > > (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead > > of the expected one. > > I don't think I understand why this happens. That's not surprising. > There is some complicated DWIM that Windows Python does when it starts > up to try to guess what should go on sys.path and in what order. Tim > Peters dug up a comment in Python's code and sent it to me a bit ago > about why this happens. It can be found in Python's PC/getpathp.c file: > > PATH RULES FOR WINDOWS: > This describes how sys.path is formed on Windows. It describes the > functionality, not the implementation (ie, the order in which these > are actually fetched is different) > > * Python always adds an empty entry at the start, which corresponds > to the current directory. > > * If the PYTHONPATH env. var. exists, it's entries are added next. > > * We look in the registry for "application paths" - that is, sub-keys > under the main PythonPath registry key. These are added next (the > order of sub-key processing is undefined). > HKEY_CURRENT_USER is searched and added first. > HKEY_LOCAL_MACHINE is searched and added next. > (Note that all known installers only use HKLM, so HKCU is typically > empty) > > * We attempt to locate the "Python Home" - if the PYTHONHOME env var > is set, we believe it. Otherwise, we use the path of our host > .EXE's > to try and locate our "landmark" (lib\\os.py) and deduce our home. > - If we DO have a Python Home: The relevant sub-directories (Lib, > plat-win, lib-tk, etc) are based on the Python Home > - If we DO NOT have a Python Home, the core Python Path is > loaded from the registry. This is the main PythonPath key, > and both HKLM and HKCU are combined to form the path) > > * Iff - we can not locate the Python Home, have not had a PYTHONPATH > specified, and can't locate any Registry entries (ie, we have > _nothing_ > we can assume is a good path), a default path with relative entries > is > used (eg. .\Lib;.\plat-win, etc) > > The end result of all this is: > * When running python.exe, or any other .exe in the main Python > directory > (either an installed version, or directly from the PCbuild > directory), > the core path is deduced, and the core paths in the registry are > ignored. Other "application paths" in the registry are always read. > > * When Python is hosted in another exe (different directory, embedded > via > COM, etc), the Python Home will not be deduced, so the core path > from > the registry is used. Other "application paths" in the registry are > always read. > > * If Python can't find its home and there is no registry (eg, frozen > exe, some very strange installation setup) you get a path with > some default, but relative, paths. > > >From this (and without a Windows machine in front of me), I can't really > make any sense out of why your Activestate Python's sitecustomize.py is > being found instead of Zope's Python sitecustomize.py if you're running > Zope using the Zope Python install. I suspect it may be because of > placement of your sitecustomize.py file and the rule named "We look in > the registry for "application paths"", but that's a guess. > > > I don't think setting up PYTHONPATH inside sitecustomize.py is a good > > idea. Better keep this mechanism for site specific problems. I'd rather > > insert a line into zopeservice.py like this. > > > > import os.path > > from os.path import dirname as dn > > import sys > > > > # these are replacements from mkzopeinstance > > PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' > > SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' > > INSTANCE_HOME = r'C:\Zope-MIB' > > ZOPE_HOME = r'C:\Zope-2.7.0' > > > > ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME > > CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') > > PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME > > > > sys.path.insert(0, SOFTWARE_HOME) > > os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line > > > > from nt_svcutils.service import Service > > > > servicename = 'Zope_%s' % str(hash(INSTANCE_HOME)) > > > > class InstanceService(Service): > > start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) > > _svc_name_ = servicename > > _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME > > _exe_name_ = PYTHONSERVICE_EXE > > > > if __name__ == '__main__': > > import win32serviceutil > > win32serviceutil.HandleCommandLine(InstanceService) > > > > > > > > This is much more palatable in my opinion. > > Does this work? On all of W2K, Win98, and WinXP? If so, I'd be glad to > ditch the current munging of sitecustomize.py. As I said, it wasn't > working for me, at least on Win2K. > > - C > > > > > > ------------------------------ > > Message: 4 > Date: Mon, 8 Mar 2004 22:27:27 -0500 > From: "Tim Peters" <tim(a)zope.com> > Subject: RE: [Zope-dev] Zopeservice and sitecustomize > To: "Sake" <sakesun(a)boonthavorn.com> > Cc: zope-dev(a)zope.org > Message-ID: <LNBBLJKPBEHFEDALKOLCEEFJJGAB.tim(a)zope.com> > Content-Type: text/plain; charset="iso-8859-1" > > [Sake] > > I have Zope and Activestate Python installed together in the same > > win-xp machine. Everything works fine until I've learned that I can > > put "sys.setdefaultencoding('cp874')" into sitecustomize.py to > > accomodate my native language coding. Since I do that, my Zope 2.7.0 > > service can no longer start. I can start it manually from > > "runzope.bat", but it never start through the windows system service. > > A full day investigation reveal that the trouble cause by the missing > > of the '<SOFTWARE_HOME>\lib\python' in the system environment's > > "PYTHONPATH". The "runzope.bat" set that up before then execution of > > "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on > > the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up > > the correct "PYTHONPATH". Here is the code inside Zope's > > sitecustomize.py > > > > """ Add Zope packages in Windows binary distro to sys.path > > automagically """ import sys > > import os > > try: > > sp = __file__ > > except: > > sp = None > > if sp: > > dn = os.path.dirname > > swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') > > if os.path.exists(swhome): > > sys.path.insert(0, swhome) > > > > Unluckily, this sitecustomize.py is now masked with my > > sitecustomize.py inside Activestate's site-package directory, which > > actually get loaded by Zope via the Python registry load path > > (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead > > of the expected one. > > It's actually a different bug: Python normally never looks at the value of > the PythonPath registry key, and that's not why your sitecustomize.py is > found first. That's actually a side effect of ActiveState installing > win32all: if you look *under* > HKLM\Software\Python\PythonCore\2.3\PythonPath, you'll find subkeys > Pythonwin, win32, and win32com. It's actually the win32com subkey that puts > your ActiveState Python's lib\site-packages into sys.path. It's then a bug > in Zope that it lets that dirty trick hide its own lib\site-packages: Zope > ships with its own Python, and *intends* to insulate you completely (in both > directions) from whatever other Python(s) you may happen to have installed > on the machine. So when that bug gets fixed, your sitecustomize.py will > never get executed. > > BTW, sys.setdefaultencoding() is almost never a good solution; working with > Unicode instead usually is. > > > > > ------------------------------ > > Message: 5 > Date: Mon, 8 Mar 2004 22:35:20 -0500 > From: "Tim Peters" <tim(a)zope.com> > Subject: RE: [Zope-dev] Zopeservice and sitecustomize > To: "Chris McDonough" <chrism(a)plope.com>, "Sake" > <sakesun(a)boonthavorn.com> > Cc: zope-dev(a)zope.org > Message-ID: <LNBBLJKPBEHFEDALKOLCOEFKJGAB.tim(a)zope.com> > Content-Type: text/plain; charset="iso-8859-1" > > [Chris McDonough] > > ... > > From this (and without a Windows machine in front of me), I can't > > really make any sense out of why your Activestate Python's > > sitecustomize.py is being found instead of Zope's Python > > sitecustomize.py if you're running Zope using the Zope Python install. > > I suspect it may be because of placement of your sitecustomize.py file > > and the rule named "We look in the registry for "application paths"", > > but that's a guess. > > Yes, and the "application path" is specifically win32com, which ActiveState > installed. That has the side effect of putting the ActiveState Python's > Lib/site-packages into sys.path, and it so happens that it ends up before > Zope's Lib/site-packages. That's why Sake's sitecustomize.py is found > first. It also so happens that all of ActiveState's win32all appears before > any of Zope's attempt to supply its own win32all, so there are multiple bugs > here. AFIAK, these subtle sys.path glitches are in all of Zope Corp's > Windows offerings, except for the very recent ZRS-for-Windows 1.4 release. > > > > > ------------------------------ > > Message: 6 > Date: Tue, 09 Mar 2004 10:21:31 +0000 > From: Chris Withers <lists(a)simplistix.co.uk> > Subject: Re: [Zope-dev] Re: Unexpected Behaviour iterating over > catalog search... > To: Jean Jordaan <jean(a)upfrontsystems.co.za> > Cc: zope-dev(a)zope.org > Message-ID: <404D9AAB.6020001(a)simplistix.co.uk> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Jean Jordaan wrote: > > > for brain in Catalog(some_index=some_value): > > # delete the object, and then > > brain_to_delete = Catalog(unique_index=brain.unique_prop) > > Catalog.uncatalog_object(brain_to_delete.getPath()) > > > > .. can't really think why that would work if Chris's original > > doesn't, though. > > ...it won't, this is analagous to the code I have that fails. > > cheers, > > Chris > > -- > Simplistix - Content Management, Zope & Python Consulting > - http://www.simplistix.co.uk > > > > > ------------------------------ > > Message: 7 > Date: Tue, 09 Mar 2004 13:36:33 +0200 > From: "Alex V. Koval" <alex(a)halogen-dg.com> > Subject: Re: [ZODB-Dev] Re: BTrees strangeness (was [Zope-dev] Zope > 2.X BIG Session problems - blocker - our site dies - need help of > experience Zope developer, please) > To: "Chris McDonough" <chrism(a)plope.com> > Cc: zope-dev(a)zope.org > Message-ID: <opr4lei7llb959jf(a)alex.halogen.kharkov.ua> > Content-Type: text/plain; charset="koi8-r" > > > Hi Chris, > > On Fri, 05 Mar 2004 13:08:01 -0500, Chris McDonough <chrism(a)plope.com> > wrote: > > >> I am monitoring site now, and will tell you about the results. > > OK, many thanks! > > Running For: 3 days 4 hours 28 min 29 sec. > > I have enabled 400 error_log ex exceptions to keep, and during 3 days I > got 2 errors > on the site: > > Time Username (User Id) Exception > 16:35:01 Anonymous User (None) KeyError: 1078763620 > 21:59:05 Anonymous User (None) KeyError: 1078696720 > > But it seems I forget to install new Transience module to the new Zope > instance. Should I? > > -- > Alex V. Koval > http://www.halogen-dg.com > http://www.zwarehouse.org >

3 2

Unexpected Behaviour iterating over catalog search...
by Chris Withers 09 Mar '04

09 Mar '04

Hi, I have something like this: for brain in Catalog(some_index=some_value): # delete the object, and then Catalog.uncatalog_object(brain.getPath()) ...which wasn't deleting all objects where some_index=some_value. On a hunch, I tried: for brain in tuple(Catalog(some_index=some_value)): # delete the object, and then Catalog.uncatalog_object(brain.getPath()) ...which magically worked. Surely the thing returned by a Catalog search should be immutable? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

5 4

Zopeservice and sitecustomize
by Sake 09 Mar '04

09 Mar '04

Hi, I have Zope and Activestate Python installed together in the same win-xp machine. Everything works fine until I've learned that I can put "sys.setdefaultencoding('cp874')" into sitecustomize.py to accomodate my native language coding. Since I do that, my Zope 2.7.0 service can no longer start. I can start it manually from "runzope.bat", but it never start through the windows system service. A full day investigation reveal that the trouble cause by the missing of the '<SOFTWARE_HOME>\lib\python' in the system environment's "PYTHONPATH". The "runzope.bat" set that up before then execution of "Zope.Startup.run.py", hence it run fine. But "zopeservice.py" rely on the "<SOFTWARE_HOME>\bin\Lib\site-packages\sitecustomize.py" to set up the correct "PYTHONPATH". Here is the code inside Zope's sitecustomize.py """ Add Zope packages in Windows binary distro to sys.path automagically """ import sys import os try: sp = __file__ except: sp = None if sp: dn = os.path.dirname swhome = os.path.join(dn(dn(dn(dn(sp)))), 'lib', 'python') if os.path.exists(swhome): sys.path.insert(0, swhome) Unluckily, this sitecustomize.py is now masked with my sitecustomize.py inside Activestate's site-package directory, which actually get loaded by Zope via the Python registry load path (HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.3\PythonPath) instead of the expected one. I don't think setting up PYTHONPATH inside sitecustomize.py is a good idea. Better keep this mechanism for site specific problems. I'd rather insert a line into zopeservice.py like this. import os.path from os.path import dirname as dn import sys # these are replacements from mkzopeinstance PYTHONW = r'C:\Zope-2.7.0\bin\pythonw.exe' SOFTWARE_HOME=r'C:\Zope-2.7.0\lib\python' INSTANCE_HOME = r'C:\Zope-MIB' ZOPE_HOME = r'C:\Zope-2.7.0' ZOPE_RUN = r'%s\Zope\Startup\run.py' % SOFTWARE_HOME CONFIG_FILE= os.path.join(INSTANCE_HOME, 'etc', 'zope.conf') PYTHONSERVICE_EXE=r'%s\bin\PythonService.exe' % ZOPE_HOME sys.path.insert(0, SOFTWARE_HOME) os.environ['PYTHONPATH'] = SOFTWARE_HOME <---------------- inserted line from nt_svcutils.service import Service servicename = 'Zope_%s' % str(hash(INSTANCE_HOME)) class InstanceService(Service): start_cmd = '"%s" "%s" -C "%s"' % (PYTHONW, ZOPE_RUN, CONFIG_FILE) _svc_name_ = servicename _svc_display_name_ = 'Zope instance at %s' % INSTANCE_HOME _exe_name_ = PYTHONSERVICE_EXE if __name__ == '__main__': import win32serviceutil win32serviceutil.HandleCommandLine(InstanceService) This is much more palatable in my opinion.

3 3

Image.tag() no longer publishable?
by Paul Winkler 05 Mar '04

05 Mar '04

I used to be able to browse to an image's tag method and see its output in my browser. This worked in zope 2.6.1 and apparently stopped working in 2.6.2. Anybody know why? I don't see ANY changes to Image.py between 2.6.1 and 2.6.2. In 2.6.2, 2.6.4, and 2.7.0 I get the "missing docstring" error: "The object at http://localhost:8080/foo.jpg/tag has an empty or missing docstring. Objects must have a docstring to be published." Well, that's a bald-faced lie... Image.tag has a nice long docstring! What the heck? Is this maybe a side-effect of a security fix somewhere else? It's very inconvenient, I used this technique to embed zope images in JSP's and all those pages are now broken. Any clue would be appreciated. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's SUBORDINATE FROM IDAHO! (random hero from isometric.spaceninja.com)

5 15

Interfaces in Zope 2.5, 2.7, and 3.x
by Terry Hancock 05 Mar '04

05 Mar '04

I have a product that uses a component/interface model internally. I wrote this against the "scarecrow" Interface module in Zope 2.5.1. However that module has limitations. One particular one is what I call a "SubInterface" -- which is a special case of Interface.Attribute (a subclass of it) that asserts that an object contained within a parent interface implements a particular interface. So, for example, a SubInterface might say that in order to conform to interface "foo", the attribute "bar" must point to an object which implements "Mapping" (e.g. a dictionary -- it doesn't have to *be* a dictionary, but it must act like one). Anyway, I wrote my own interface module to do this, extending the Interface module in Zope 2.5.1 (which lacks this feature). All of my code actually imports interface support from my module instead of directly from Interface. For unrelated reasons, though, I had to upgrade to Zope 2.7 (and someday, I imagine I'll want to consider moving to Zope 3.x). My first attempt with Zope 2.7, though yields total breakage! The Interface module has been extensively overhauled, method names changed, etc. After giving up on "just fixing a few name- changes", which seems to be woefully inadequate, I decided to try to lift the old Interface module -- but now Zope reads the "__implements__" attribute and isn't happy if it isn't one of its own interface objects! """ Installing Narya ... Traceback (most recent call last): File "./testNaryaInterface.py", line 11, in ? ZopeTestCase.installProduct('Narya') File "/usr/local/narya/z2.7.0/lib/python/Testing/ZopeTestCase/ZopeLite.py", line 119, in installProduct get_folder_permissions(), raise_exc=1) File "/usr/local/narya/z2.7.0/lib/python/OFS/Application.py", line 732, in install_product initmethod(context) File "/usr/local/narya/zope/Products/Narya/__init__.py", line 25, in initialize icon='www/Icon/Thread.gif') File "/usr/local/narya/z2.7.0/lib/python/App/ProductContext.py", line 176, in registerClass interfaces = instancesOfObjectImplements(instance_class) File "/usr/local/narya/z2.7.0/lib/python/Interface/Implements.py", line 120, in instancesOfObjectImplements visitImplements(implements, klass, r.append, getInterface) File "/usr/local/narya/z2.7.0/lib/python/Interface/Implements.py", line 90, in visitImplements raise Exceptions.BadImplements( Interface.Exceptions.BadImplements: __implements__ should be an interface or tuple, not a instance pretending to be a Interface """ (Seems I'm a pretender ;-) ). Now, I can implement a new module based on the Zope 2.7 Interface -- but a close look at that seems to show that it, too, is rather experimental (lots of stubs, not-yet-implemented attributes, etc). So I'm also sort of interested in the "interface" module in Zope X3. It appears that some new bells and whistles have been added to the Interface module (e.g. what's a "superinterface"?). Any chance, I'm wondering if "SubInterface" is now redundant? Also, is there a general guide to "best practice" of using / learning the Interface module? I note there are now interfaces defined for the interface module (cool!), and it looks like some self-documentation has been implemented. The biggest problem (and this seems to be the usual problem with "self-documenting" tools) is that there doesn't seem to be a "start here" defined anywhere. So you wind up starting somewhere in the middle and wasting a lot of time trying to decipher the big picture from lots of details, which is backwards. It'd be nicer if there was a "README" to get you started on this, maybe define some jargon, etc. It's really hard to infer what the overall design concept is by only looking at these details -- in particular, I want to know what was conceptually changed from the older Interface module in 2.5.1. This seems to also be a problem with combining Zope 3 and Zope 2 interfaces, as was suggested by a post on the Zope3 mailing list: http://mail.zope.org/pipermail/zope3-dev/2003-December/009023.html (and following -- note that "__interfaces__" should read "__implements__" in the original post). Martijn's suggestion was to use an alternate name for the "__implements__" attribute. I suppost I could do that -- call mine "__narya_interfaces__", but that sounds ugly. In particular, I don't really want my interfaces module to actually *conflict* with Zope's. I also note that the post from the Zope3 list suggests that I shouldn't really be directly assigning "__implements__", but using something called "implements()". Hmm. That's different too -- is there any good starting place for understanding Zope3's "interface" module? And how different are the Zope 2.7 / Zope X3 interface modules? If I re-write my module to conform to Zope 2.7, will I just have to do it again? Could I instead leap ahead and use the Zope X3 interface module in Zope 2.7? Also, since I'm posting to Zope3-dev as well -- what do you think of the SubInterface concept? Should I be contributing code directly to Zope X3's interface instead of subclassing it? All it requires is something like: """ class SubInterface(Attribute): """ A SubInterface is an Attribute with an assigned Interface. """ def __init__(self, __name__=None, __doc__=None, api=None, optional=0): self.__name__=__name__ self.__doc__=__doc__ or __name__ self.api = api self.optional = optional """ Which is what my module defines -- the trickier bit is defining a function to recursively check SubInterfaces. That's included too, but it breaks due to major API changes in Interface. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com

4 4

Execution context
by Garito 05 Mar '04

05 Mar '04

Hi all Finally I solve my problem with Tres Seaver's help (THANK YOU) I override the __bobo_traverse__ with: def __bobo_traverse__(self, Request, Name): import sys if sys._getframe(1).f_code.co_name == "traverse": return getattr(self, Name) else: return self.Propiedad(Name) self.Propiedad is the fuction than neutralices (I call these mechanism Neutralization) the content of my object When You executes ZMI sys._getframe(1).f_code_co_name returns traverse Thanks again Tres Seaver!

2 1

help
by Vandana Bajaj 05 Mar '04

05 Mar '04

I am not able to access zope management interface through mozilla. Could any one guide me why is it happening so. Can i use Javascript within Zope Page Templates to embed logic Thank you in advance Vandana --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster.

2 1