- Zope-Dev - Zope lists

Re: Creating a namespace
by Michael Halle 28 Jan '01

28 Jan '01

Stephan Richter <srichter(a)cbu.edu> writes: > I want to make my own name space with the following situation: > class X: > attributes = {'foo': 'bar'} > x = X() > Then I want to use it like that: > <dtml-with x> > <dtml-var foo> > </dtml-with> I puzzled through a related problem a little, but for (I think) a different reason. I have an External Method that takes a significant amount of time to run, and returns a collection of data. I didn't want to have to push the names of all the subvariables returned onto the stack; that pollutes the name space. What I wanted to do was the following: <dtml-let x="MyExternalMethod(arg1, arg2)"> Variable 1: <dtml-var expr="x.variable1"> <br> Variable 2: <dtml-var expr="x.variable2"> <br> </dtml-let> (But, as in your case, I could also have done: <dtml-with expr="MyExternalMethod(arg1, arg2)"> Variable 1: <dtml-var expr="variable1"> <br> Variable 2: <dtml-var expr="variable2"> <br> </dtml-let> ) To me, this first example seemed like a pretty common and obvious thing to to. I didn't need "x" to be persistent, I didn't need or want acqusition, I just wanted to keep my variables containerized in a structure. For this purpose, FunctionTemplate, InstanceDict, and TemplateDict all seemed either inappropriate, too complex, or too heavyweight. So, I wrote the simple container class at the end of this message that contains a grab-bag of methods that can be used for my application as well as with a variety of others that use <dtml-with> and <dtml-in>. It essentially provides all that "_.namespace()" does, plus some extra introspection. It's concocted from various pieces of Zope and the HowTos. Now, philosophical Zope questions: * To those in the know, is there any problems returning non-persistent structures? * Next, it there a reason that there's no sanctioned class for this purpose? * Can you return a populated namespace from a DTML Method or a Python Script using existing mechanisms? * Why can't you set values in "_.namespace()" in DTML after a namespace has been created? * To me, it would make so much more sense to be able create a namespace with temporary variables (as shown in one of the HowTos) rather than forcing people to hack them using REQUEST.set(). The namespace could be used directly as a structure (eg, "ns.x") or as a scope (eg, <dtml-with ns> <dtml-var x> </dtml-with> ). Is there a deep reason it doesn't exist? Anyway, here's my "no-guarantee" class. Notice the magic member "__allow_access_to_unprotected_subobjects__", which the documentation (read, code) says can also be set to a list of members that you want to be publicly accessible and unprotected. Use this code as a guide; you can trim it down to get what you want. An instance of this class can be used directly as an argument to <dtml-with>; to use with <dtml-in>, use either the "getItems" or "getMap()" methods. ------------------------------------- class StructureInstance: """A simple, non-persistent, class-based dictionary that's useful for returning arguments to Zope""" __allow_access_to_unprotected_subobjects__ = 1 def __init__(self, dict={}): self.__d=dict def __getattr__(self, name): try: return self.__d[name] except KeyError: raise AttributeError, name def __getitem__(self, name): try: return self.__d[name] except KeyError: raise KeyError, name def __setitem__(self, name, value): self.__d[name] = value def update(self, dict): self.__d.update(dict) def getKeys(self, spec=None): if spec is None: return self.__d.keys() return filter((lambda x, spec=spec: x in spec), self.__d.keys()) def getValues(self, spec=None): if spec is None: return self.__d.values() return map(lambda y: y[1], filter((lambda x, spec=spec: x[0] in spec), self.__d.keys())) def getItems(self, spec=None): if spec is None: return self.__d.items() return filter((lambda x, spec=spec: x[0] in spec), self.__d.items()) def getMap(self, spec=None): items = self.getItems(spec) dict = {} for (i, j) in items: dict[i] = j return dict def set(self, **args): self.update(args) setitem=__setitem__ ----------------------------------------------- Michael Halle mhalle(a)media.mit.edu

1 0

ZCatalog FieldIndex bug in Zope 2.3.0b3
by Chris Withers 28 Jan '01

28 Jan '01

Hi, FieldIndex's don't work quite right in 2.3. Try this: - create a Catalog with a FieldIndex called 'test' - create a DTML document with a property 'test', value 'fish' - catalog the document - now change the value of the property to 'finger' and re-catalog. If you now search for test='finger' it'll return the document. However, if you search for test='fish', it will also return the document, which is wrong. cheers, Chris PS: Tabular reporting ZSearch Interfaces generated from Catalogs have quite badly b0rKen results forms, in that, for some reason, the search form ends up in a column of the results table, very confusing...

4 8

Looks like 2.3.0 final didn't fix bug with copying ZCatalogs ...
by Bill Anderson 28 Jan '01

28 Jan '01

...but the error message looks better ;^)= Installed fresh 2.3.0, and Membership, so I could finish the testing, and preop a 2.3.0 compatible release (mmm Python Scripts yummy....), but upon the install trying to copy the MemberCatalog I get the following traceback. Perhaps it is an issue with PythonMethods, but it looks like it is ZCatalog to me. ======================================================== The object MemberCatalog does not support this operation Traceback (innermost last): File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 187, in publish File /local/ZopeSites/anderson-2.3/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: RoleManager) File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 171, in publish File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: doInstall) File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: doInstall) File /local/ZopeSites/anderson-2.3/lib/python/Products/PythonMethod/PythonMethod.py, line 168, in __call__ (Object: doInstall) (Info: ((<Factory instance at 897f0c8>, 'on', None, None, 0, 'webadmin', (snip raw html data from form) File <string>, line 47, in doInstall (Object: RoleManager) File /local/ZopeSites/anderson-2.3/lib/python/Products/PythonMethod/PythonMethod.py, line 168, in __call__ (Object: copyInterface) (Info: ((<Factory instance at 897f0c8>, <LoginManager instance at 89c4a28>, []), {}, (None,))) File <string>, line 5, in copyInterface (Object: RoleManager) File /local/ZopeSites/anderson-2.3/lib/python/OFS/CopySupport.py, line 333, in manage_clone (Object: ProviderContainer) File /local/ZopeSites/anderson-2.3/lib/python/OFS/CopySupport.py, line 421, in _verifyObjectPaste (Object: ProviderContainer) Copy Error: (see above) ====================== .... yup, just tried to copy the MemberCatalog, same result: Traceback (innermost last): File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 187, in publish File /local/ZopeSites/anderson-2.3/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 171, in publish File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_pasteObjects) File /local/ZopeSites/anderson-2.3/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_pasteObjects) File /local/ZopeSites/anderson-2.3/lib/python/OFS/CopySupport.py, line 215, in manage_pasteObjects (Object: ApplicationDefaultPermissions) File /local/ZopeSites/anderson-2.3/lib/python/OFS/CopySupport.py, line 421, in _verifyObjectPaste (Object: ApplicationDefaultPermissions) Copy Error: (see above) -- Bill Anderson Linux Specialist Modular Network Storage R&D Random Quote: Portable: survives system reboot.

2 1

Re: [Zope-dev] ZCatalog and 'fuzzy logic'
by Dieter Maurer 28 Jan '01

28 Jan '01

Morten W. Petersen writes: > Is there anyone who could try to give an estimate of how long it would > take to add fuzzy logic (regexp-like) searching capability to the > ZCatalog? I do not think that "fuzzy logic" is strongly related to "regexp-like". Anyway. Fuzzy searching often means "finding matches with characters omitted, replaced or inserted". Zope's globbing vocabularies support wildcards '*' and '?'. To implement wildcard based searches efficiently, they index words under their two letter consitutents. When you now get a pattern, you derive from the pattern what two letter constituents the matching words must have and retrieve them. This defines a candidate word set. Then you check, whether the retrieved word really match the expression. You can extend this algorithm to get fuzzy searches. Dieter

4 4

Creating a namespace
by Stephan Richter 28 Jan '01

28 Jan '01

Hello everyone, I want to make my own name space with the following situation: class X: attributes = {'foo': 'bar'} x = X() Then I want to use it like that: <dtml-with x> <dtml-var foo> </dtml-with> The result should be : bar I found out that I have to somehow use TemplateDict and InstanceDict, but I have no clue how to use it....Of course there is no documentation on any web site or in the Zope code itself.... Thanks for you help!!! Regards, stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management

3 4

One Zope playing with another Zope
by Chris Withers 28 Jan '01

28 Jan '01

> On Saturday 27 January 2001 03:26, Tres Seaver wrote: > > > > Even more insidious, consider: > > :py import Zope; app=Zope.app() Well, of course, I'd like to do this from a python script between Zope instances ;-) So, a coupla questions: Why do you have to be running ZEO to do this? Where would I import another instance of Zope from if I wanted to play with it from the instance of Zope I'm currently in? cheers, Chris

1 0

Added rename to ZOPE FTP server
by Tom Vijlbrief 28 Jan '01

28 Jan '01

Hi, I've added the rename capability to the Zope FTP-server, so I could use the KDE FTP client (this is a known Zope bug). I attached the 3 modified files (from the 2.2.5 src distro). There is however another problem in the ZOPE ftpd which is probably not related to my patches, but for which I have not found the cause. The SIZE command (used by the KDE ftp-client as a kind of file-exists probe) reports the size of identical named objects higher in the tree, to reproduce: copy with the KDE FTP client a directory tree which has fileabc in the top directory and a file "fileabc" in a subdirectory to the Zope ftp server. The SIZE command returns a size (for a non existing object!) but the LIST command works o.k. (reports an error: could not list directory) 127.0.0.1:3771 <== mkd testdir 127.0.0.1:3771 ==> 257 MKD command successful. 127.0.0.1:3771 <== mkd testdir/adir 127.0.0.1:3771 ==> 257 MKD command successful. 127.0.0.1:3771 <== type I 127.0.0.1:3771 ==> 200 Type set to Binary. 127.0.0.1:3771 <== SIZE testdir/fileabc 127.0.0.1:3771 ==> 550 Error getting file size. 127.0.0.1:3771 <== type I 127.0.0.1:3771 ==> 200 Type set to Binary. 127.0.0.1:3771 <== SIZE testdir/fileabc.part 127.0.0.1:3771 ==> 550 Error getting file size. 127.0.0.1:3771 <== type I 127.0.0.1:3771 ==> 200 Type set to Binary. 127.0.0.1:3771 <== PASV 127.0.0.1:3771 ==> 227 Entering Passive Mode (127,0,0,1,14,190) 127.0.0.1:3771 <== stor testdir/fileabc.part 127.0.0.1:3771 ==> 150 Opening Binary connection for testdir/fileabc.part 127.0.0.1:3771 ==> 226 Transfer complete. 127.0.0.1:3771 <== RNFR testdir/fileabc.part 127.0.0.1:3771 ==> 350 RNFR command successful. 127.0.0.1:3771 <== RNTO testdir/fileabc 127.0.0.1:3771 ==> 250 RNTO command successful. 127.0.0.1:3771 <== SITE CHMOD 644 testdir/fileabc 127.0.0.1:3771 ==> 500 'SITE': command not understood. 127.0.0.1:3771 <== type I 127.0.0.1:3771 ==> 200 Type set to Binary. 127.0.0.1:3771 <== SIZE testdir/adir/fileabc 127.0.0.1:3771 ==> 213 2 127.0.0.1:3771 <== cwd testdir/adir/fileabc 127.0.0.1:3771 ==> 550 No such directory. 127.0.0.1:3771 <== type A 127.0.0.1:3771 ==> 200 Type set to ASCII. 127.0.0.1:3771 <== PASV 127.0.0.1:3771 ==> 227 Entering Passive Mode (127,0,0,1,14,192) 127.0.0.1:3771 <== list testdir/adir/fileabc 127.0.0.1:3771 ==> 550 Could not list directory. -- Tom Vijlbrief tom.vijlbrief(a)ision.nl

3 4

asynchat producer ready() method patch.
by Donovan Baarda 27 Jan '01

27 Jan '01

G'day zope-dev, I'm not subscribed to the zope-dev list (got enough email thanks :-), but I thought some of you might be interested in the following patch to medusa that I sent to the medusa list (ZServer is based on medusa). I remember reading ages ago on a wishlist for ZServer that someone was thinking of adding blocking support to producers. This patch adds support for just that in a non-intrusive way. I haven't tried applying this patch to ZServer, but it _should_ work. The two things to look out for when applying these changes to older programs that use asynchat.py and producers.py are; old producers with existing and conflicting ready() methods, anything that uses the compound_producer because the __init__ method has been simplified. I hope someone finds this useful, and would appreciate any feedback. Thanks, ABO ----- Forwarded message from Donovan Baarda <abo(a)minkirri.apana.org.au> ----- G'day, I've recieved one note of interest in my patch for medusa to allow producers to block using a ready() method. The gist was "this is a good idea, but it doesn't work". At the time I was focusing on the ftp server part of medusa, so I hadn't checked the http side much at all. I also noticed that asyncore.py and asynchat.py were distributed without producers.py in python itself. My original changes made asynchat.py dependant on producers.py, which was probably a bad idea. So I have gone right over my changes and produced a new, more thoroughly tested patch that tries to minimize the side affects. I have tested the changes as they are incrementaly applied to ensure that my changes don't break old code that doesn't use the ready() feature. This patch contains all changes made to all files, but you only need to accept the changes to some files to use ready() The main change is to asynchat.py, where support for the ready() method has been added. Also added are a variety of producer base classes that allow new producers with ready() support to be easily derived (and removed the asynchat.py dependancy on producers.py that my early patch introduced). The main async_chat class is actualy significantly simpler for the change, mostly due to replacing the fifo class with a fifo_producer class. The find_prefix_at_end procedure for finding terminators has also been simplified and speeded up. Overall, asynchat.py is only 23 lines bigger dispite all the additional functionality. The good news is, the changes to asynchat.py are fully backwards compatible and medusa runs fine with all other files unchanged, _except_ that filesys.py and status_handler.py have conflicting ready() methods in producers. These ready() methods are unused in the original medusa, but cause the new asynchat.py to think the producers never complete. The patch to these two files simply removes these ready() methods so medusa can run with the new asynchat. The next lot of serious changes are to producers.py and http_server.py. These changes are not needed to run medusa as it stands, but are needed if you start using blocking producers. The changes primarily make the producers inherited from the base producer classes defined in asynchat.py. This ensures that producers that wrap other producers will block correctly. The inheritance of features makes producers.py 62 lines smaller than it was. All the changes to producers.py are backwards compatible _except_ the compound_producer.__init__() method now takes a python list of producers not a fifo. The changes to http_server.py take this into account. The final trivial change is a commented out alternative to use the new async_producer instead of file_producer in ftp_server.py. This allows medusa filesystems to return file types that could block without blocking the whole server. I hope someone gets a chance to try these out, and I would appreciate any form of feedback. I'm tempted to submit my patch to asynchat.py direct to the Python people for inclusion in Python 2.1, but would like to hear more feedback before I do. BTW, ignore the patch to "medusa.prj"... that is a side affect of using prcs to revision control my changes. This patch is to the 20000601 version of medusa. -- ---------------------------------------------------------------------- ABO: finger abo(a)minkirri.apana.org.au for more info, including pgp key ----------------------------------------------------------------------

1 1

QNX and Zope
by Joachim Werner 27 Jan '01

27 Jan '01

Hi! Is there anyone who has tried using Zope on QNX? I have a request for using Zope in an embedded environment. Thanks! Joachim

1 0

ANNOUNCE: Zope 2.3.0 final released
by Brian Lloyd 26 Jan '01

26 Jan '01

Hello all, Zope 2.3.0 final has been released - you can download it from Zope.org: http://www.zope.org/Products/Zope/2.3.0/ Zope 2.3 is focused on improving productivity, ease of use and performance. New features in the 2.3 release supporting these goals include: - Scripts to allow safe web management of logic, dramatically improving the ability to separate logic and presentation in site design - Cache Managers to provide a powerful caching infrastructure for dramatically improving site responsiveness while retaining dynamicism - Built-in infrastructure for complex virtual hosting of multiple sites on one server - Significantly improved Zope Management Interface for web-based authoring and administration - Other important changes, such as improvements in WebDAV support, customizable object creation, running an optional server for browsing source documents, significant improvements in cataloging and indexing, and a new quick start document with references to the most important documentation for new users Zope 2.3 also marks the first feature release where a significant amount of the work was done "in the fishbowl" using our open development process on dev.zope.org. This release owes a lot to the hard work of many in the Zope community in addition to folks here at DC. The MVPs for Zope 2.3 include: - Evan Simpson (Python scripting and SiteAccess) - Shane Hathaway (CacheManager and many other things) - Adam Davis (improvements to the Zope interface) - Chris Petrilli (ZCatalog) - Toby Dickenson (improved Python 2 support) - Chris McDonough (improved UserFolders) - John Odom (StructuredText NG) - Michel Pelletier (Interfaces and new Quickstart) - Casey Duncan (ZCatalog patches) - Tres Seaver (FTP and DAV support in ZClasses) - John Heintz (patch for ExtensionClass) - Chris Withers (patches and bug hunting) - Tom Vijlbrief (FTP rename support) - Dieter Maurer (patches and bug hunting) My apologies to anyone I've missed - thanks also to the many who participated the alpha and beta cycles and provided feedback. For more information on what is new in this release, see the CHANGES.txt and HISTORY.txt files for the release: - http://www.zope.org/Products/Zope/2.3.0/CHANGES.txt - http://www.zope.org/Products/Zope/2.3.0/HISTORY.txt Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1