March 2004 - Zope-Dev

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

Schizophrenic ObjectManager?
by Ian Beatty 05 Mar '04

05 Mar '04

Greetings. I'd like to create a type in a Python-based product that's kind of like two folders fused together. What I mean by that is I've got a folderish object type -- let's call it 'F' -- that inherits from ObjectManager. I've set it up so that it can contain objects of type 'A' and nothing else, by using the all_meta_types property. So far so good. Now, I want to have it also contain objects of type 'B', but displayed and managed through a separate tab in the ZMI. If I click on the "Contents" tab of an instance of F, I get the list of contained A-type objects, with cut, copy, paste, delete, etc. If I click on another tab named, say, "OtherStuff", I want to see exactly the same kind of contents-list management page, but for contained B-type objects. I'm thinking that I might try having F contain an instance of ObjectManager as a property, and delegate all B-managing functionality to that. Management of A would be handled through F's inherited ObjectManager behavior. What concerns me is that the "encapsulated" second ObjectManager wouldn't have a container in the usual way, and that could seriously mess up acquisition. Another possibility is to maintain only one collection, but to create the illusion of two separate collections by having two copies of the contents ('manage_main') page, each modified to display only one kind of child. Any thoughts, oh masters of Zope Zen? Cheers, ..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

RE: [Zope-dev] TCPWatch or other such tool
by Bjorn Stabell 05 Mar '04

05 Mar '04

Shane wrote: [...] > Other people have reported this, but I can't reproduce it. I've been > using tcpwatch on Python versions 2.1 through 2.3 without a > hiccup. Are you using Linux? If so, what distribution? > > As a workaround, you can use "-s" to dump to stdout. Thanks. I was running it on Debian, so it's most likely a python-tk problem as also reported by Christian Theune. When I ran it under Windows it worked fine. I'll report it as a Debian bug. Bye, -- Bjorn

1 0

Folderish object's __call__ fails
by Dirksen 04 Mar '04

04 Mar '04

Hi, I'm developing a product, which extends ObjectManager. Meanwhile, I'd like it to behave like a script object, similar to DTML method. So I define a __call__ method. But it never gets run if called from the browser. If I change the base class to SimpleItem, it works. How can I make __call__ works for folderish object? cheers Dirksen __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

2 1

Custom class: cut,copy,rename?
by Ian Beatty 04 Mar '04

04 Mar '04

Greetings. I've created a package in Python with some basic classes. They work in the ZMI, except for the fact that the ZMI paste and rename functionality fails with the message "The object xxx does not support this operation." I've dug into the source code for standard types ('OFS.Folder', 'OFS.SimpleItem', etc.) and discovered some tantalizing bits (such as 'manage_renameObject' in 'OFS.CopySupport'), but I can't figure out how to put it together to make my classes renameable and pasteable. I'm rather surprised that behavior doesn't come automatically when inheriting from the standard base classes. One of my folderish classes subclasses the following bases: OFS.ObjectManager.ObjectManager Products.ZCatalog.CatalogPathAwareness.CatalogAware OFS.PropertyManager.PropertyManager OFS.SimpleItem.SimpleItem Am I not inheriting from the proper set of base classes? Is there an easier way? According to the ZDG (2.4 edition, vs. my Zope 2.7), OFS.SimpleItem.Item (subclassed by OFS.SimpleItem.SimpleItem) is supposed to provide cut-and-paste functionality. So, how might I be breaking it? Bewildered, ..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/ -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- -- --- --

5 8