January 2001 - Zope-Dev

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

Fw: apparent problems with LocalFS after zope upgrade
by Jonothan Farr 26 Jan '01

26 Jan '01

I'm getting reports of some very strange behavior with Zope 2.2.5 using the LocalFS product, which seems to involve the authentication mechanism somehow. I'm rather at a loss where to even begin troubleshooting here. If anyone has any suggestions they would be much appreciated. Thanks, --jfarr ----- Original Message ----- From: "Kent Polk" <kent(a)tiamat.goathill.org> To: "Jonothan Farr" <jfarr(a)speakeasy.org> Sent: Friday, January 26, 2001 9:25 AM Subject: Re: apparent problems with LocalFS after zope upgrade > Unders some (unknown) conditions, subdirectories under a localfs > mount point can no longer be found: > > <TD WIDTH="90%"> > <H2>Zope Error</H2> > <P>Zope has encountered an error while publishing this resource. > </P> > <P><STRONG>Resource not found</STRONG></P> > > Sorry, the requested Zope resource does not exist.<p>Check the URL and try > again.<p> >  > > ... > > <!-- > Traceback (innermost last): > File /usr/pkg/share/zope/lib/python/ZPublisher/Publish.py, line 222, in > publish_module > File /usr/pkg/share/zope/lib/python/ZPublisher/Publish.py, line 187, in > publish > File /usr/pkg/share/zope/lib/python/Zope/__init__.py, line 221, in > zpublisher_exception_hook > (Object: pysrc) > File /usr/pkg/share/zope/lib/python/ZPublisher/Publish.py, line 162, in > publish > File /usr/pkg/share/zope/lib/python/ZPublisher/BaseRequest.py, line 338, in > traverse > File /var/zope/Products/LocalFS/LocalFS.py, line 462, in __bobo_traverse__ > (Object: pysrc) > File /usr/pkg/share/zope/lib/python/ZPublisher/HTTPResponse.py, line 529, in > notFoundError > NotFound: (see above) > > Note that 'macpysrc' folder (above) shows up in the default directory > listing, but the above is what I get when I select it. Files which > are contained within the directory are available though... Only > the direcoty listing is not, and this is true whether there is an > index.html file in the directory or not (as well as one in the > parent-mount point or not). > > --------- > > I did note that when entering the subdirectories (using localfs) > the authentication mechanism had lost track of who I was and I was > now an Anonymous User. This doesn't happen with all LocalFS mount > points though, and haven't been able to determine what is different > between the ones that work correctly and the ones that don't except > that the ones that don't were fairly recently created using Zope-2.2.4 > LocalFS v0.9.4 while the ones that do work were created last summer > sometime. > > Note that this is observed on two different zope servers - different > hosts - using both Localfsv0.9.4 and Localfsv0.9.6. Again, this > appeared almost immediately after I upgraded to Zope-2.2.5. I had > already upgraded both servers before I noticed the problem. :^( > > Any suggestions on what to check? > > Thanks! >

1 0

FW: Re: [Zope-dev] Passing arguments to DTML Methods
by Jon Franz 26 Jan '01

26 Jan '01

PS: my example assumes you _only_ want passed arguments to be usable to the DTML method you are calling - if you want to pass parameters And get the default namespace, you have to pass it ('_') also. My util methods that use params Only use those params (I try to keep a clean interface) - but yours might not... >-----Original Message----- >From: Jon Franz >Sent: Friday, January 26, 2001 2:07 PM >To: 'ceeesf(a)cee.hw.ac.uk' >Cc: 'zope-dev(a)zope.org' >Subject: Re: [Zope-dev] Passing arguments to DTML Methods > > >This is an undocumented (afaik) feature of DTML methods/documents - due to the way python >argument mapping works, you can pass any value into a 'local' variable in a DTML method like thus: > ><dtml-var "myDTMLmethod(foo=5,greg=Sally)"> > >this the above case, Sally could be a legal variable value that will be put into the new local greg >in your DTML method, and one named foo with the value of 5. AFAIK this is pass-by-value, so modifying greg in your called method >will not change sally, but I could be wrong... >I use this sort of thing quite often in one of my ongoing projects where I need to reformat >dates strings from their mysql format to how the client wants to view them... I have a method named >undb_dateout that uses a variable called 'dbdate' and does some string splitting and formatting to output it. >Originally, I would do things like this with the method: > ><dtml-call "REQUEST.set('dbdate', currentdatevar)"> ><dtml-var undb_dateout> > >Then, on a whim I changed this to: ><dtml-var "undb_dateout(dbdate=currentdatevar)"> > >And it worked... >Someone should add this to the DTML documentation, or at least make it stand out more - it is VERY >useful... If no one else does I'll write-up a how-to on it. > >>>> >>Message: 7 >>Date: Thu, 25 Jan 2001 19:13:59 +0000 (GMT) >>From: Espen Sorbye Frederiksen <ceeesf(a)cee.hw.ac.uk> >>To: <zope-dev(a)zope.org> >>Subject: [Zope-dev] Passing arguments to DTML Methods <<SNIP>> >>Espen

1 0

Re: [Zope-dev] Passing arguments to DTML Methods
by Jon Franz 26 Jan '01

26 Jan '01

This is an undocumented (afaik) feature of DTML methods/documents - due to the way python argument mapping works, you can pass any value into a 'local' variable in a DTML method like thus: <dtml-var "myDTMLmethod(foo=5,greg=Sally)"> this the above case, Sally could be a legal variable value that will be put into the new local greg in your DTML method, and one named foo with the value of 5. AFAIK this is pass-by-value, so modifying greg in your called method will not change sally, but I could be wrong... I use this sort of thing quite often in one of my ongoing projects where I need to reformat dates strings from their mysql format to how the client wants to view them... I have a method named undb_dateout that uses a variable called 'dbdate' and does some string splitting and formatting to output it. Originally, I would do things like this with the method: <dtml-call "REQUEST.set('dbdate', currentdatevar)"> <dtml-var undb_dateout> Then, on a whim I changed this to: <dtml-var "undb_dateout(dbdate=currentdatevar)"> And it worked... Someone should add this to the DTML documentation, or at least make it stand out more - it is VERY useful... If no one else does I'll write-up a how-to on it. >>> >Message: 7 >Date: Thu, 25 Jan 2001 19:13:59 +0000 (GMT) >From: Espen Sorbye Frederiksen <ceeesf(a)cee.hw.ac.uk> >To: <zope-dev(a)zope.org> >Subject: Message: 7 >Date: Thu, 25 Jan 2001 19:13:59 +0000 (GMT) >From: Espen Sorbye Frederiksen <ceeesf(a)cee.hw.ac.uk> >To: <zope-dev(a)zope.org> >Subject: [Zope-dev] Passing arguments to DTML Methods > >Sorry this, possibly, very trivial question: > >How do you pass on variables to a DTML Method. >If I would use a python method I would use <dtml-call "pythonmethod(var1, >var2)">. This does not work with DTML Methods. First of all why? Secondly >how is it possible to get around the problem? > >Hope someone kindly could answer my question, > >Espen > > > >

1 0

Server seems to stop responding.
by Andy McKay 26 Jan '01

26 Jan '01

OS: Win2K Zope: 2.2.4b1, using ZServer direct Site, large catalog roughly 20,000 items, database size 839 MB. Problem: Zope's running quite happily, and then all of a sudden will stop responding to incoming requests. A restart and its fine. There is no memory leak (memory usage is very low), no other resources consuming space. All log files say nothing. There seems to be no obvious trigger or thing to cause it, only time (or use). Im at wits end to figure out: a) where to start debugging (apart from log files, Control Panel debug etc) and b) solution... Any help will get my undying gratitude... -- Andy McKay.

2 2

Re: [Zope-dev] ZCatalog FieldIndex bug in Zope 2.3.0b3
by Chris McDonough 26 Jan '01

26 Jan '01

This is fixed in CVS. ChrisP works fast. :-) ----- Original Message ----- From: "Chris Withers" <chrisw(a)nipltd.com> To: "Chris McDonough" <chrism(a)digicool.com> Sent: Friday, January 26, 2001 11:23 AM Subject: Re: [Zope-dev] ZCatalog FieldIndex bug in Zope 2.3.0b3 > Chris McDonough wrote: > > > > I've put the fieldindex bug in the collector. > > Thanks... wasn't sure whether it was collector material or not :-) > > Chris >

1 0

Key error using manage_changeProperties
by Espen Sorbye Frederiksen 26 Jan '01

26 Jan '01

I am pssing the category argument to the method below. The category variable is representing a propety of the Log object. My code below works ok when I get the property (1), but fails when I try to update that property (2) with a new value. I have tried to use _[category] but it disallowes the use of expression, understandably, as a keyword. Any ideas how I can get around this problem? Cheers, Espen <dtml-let (1)value="_.getattr(userFolder,username).Log.getProperty(category)" newvalue="value+......."> (2)<dtml-call "_.getattr(userFolder,username).Log.manage_changeProperties(category=newvalue)"> </dtml-let>

1 0

AttributeError when adding ZClass product (PortalMembership)
by morten＠esol.no 26 Jan '01

26 Jan '01

Hi guys, I have a problem with a product. This product, let's call it product SuperSecret, adds a number of folderish objects to the new instance when it is created. Now, if we name the SuperSecret product instance for a, and the class instance that raises the AttributeError b, I will show you what happens: I am at the root folder of the Zope instace, and select the SuperSecret entry from the Products list. There I enter the relevant information, and submit the form. But then, the SuperProduct raises an exception when the manage_add_some_class function tries to add the new b instance to the a instance. (No exception is raised when the offending line which tries to access the Control_Panel via the b instance & acquisition is commented out). The manage method, which looks like this: def manage_add_b(self, id, description, REQUEST=None): "Add an instance of the b class." self._setObject(id, b(id, description)) #get_transaction().commit() Shared.utils.install_authentication_folder(self[id]) which calls an external function, which looks like this: def install_authentication_folder(container): container.Control_Panel.Products.PortalMembership.doInstall(folder=container, REQUEST={}) which raises an AttributeError that looks like this: Zope Error Zope has encountered an error while publishing this resource. Error Type: AttributeError Error Value: Control_Panel [...] File /home/morten/Zope/lib/python/Products/rs/rs.py, line 56, in manage_add_a File /home/morten/Zope/lib/python/Products/SuperSecret/a.py, line 168, in __init__ (Object: CatalogAware) File /home/morten/Zope/lib/python/Products/SuperSecret/b.py, line 61, in manage_add_b (Object: CatalogAware) File /home/morten/Zope/lib/python/Products/SuperSecret/Shared/utils.py, line 211, in install_authentication_folder (Object: CatalogAware) AttributeError: (see above) Now, I guess this could be because the new instance isn't aware of it's surroundings, but I've tried to manually commit the transaction (which could help?), but obviously didn't... =) I guess it could be a solution to call a number of methods after the product instance is added, but that's a bit too hackish for me. Any ideas? Thanks in advance, Morten

1 0