- Zope-Dev - Zope lists

Something doesn't seem quite right with CopySupport.py/Moniker.py
by Kevin Dangoor 18 Aug '99

18 Aug '99

Hi, I posted a couple messages late last week about copying and pasting objects from DTML and Python... Looking at the source for CopySupport.py, I don't *think* I should be running into the problem that I am seeing. Here is my function: def candp(fobj, tobj): "Copy and paste" ids = fobj.objectIds() if not ids: return cdata = fobj.manage_copyObjects(ids) tobj.manage_pasteObjects(cdata) The parameters are basically the source object and the destination object. The DTML that calls this method is passing in a Folder as the source and a KMArticle as the destination. cdata is getting set to an encoded string that is roughly 105 bytes in length. When the manage_pasteObjects call is made, I get an error that the object is not found. >From manage_pasteObjects in CopySupport.py: for j, d in cp[1]: m.jar=j m.ids=d try: ob=m.bind(self._p_jar) except: raise CopyError, eNotFound So, basically it appears that the Moniker object can't bind to the original object. But, why would this be the case? The copy call was just made on the previous line, and the data returned by that call seemed valid. I can copy and paste the objects from the management interface, and the cookie that gets set looks the same... Is there something that I'm missing here? I didn't see any big difference between the management interface calling these routines and my python calling them... Thanks, Kevin

1 0

z2.py wishlist: Setting PID_FILE with command-line option
by Gregor Hoffleit 17 Aug '99

17 Aug '99

A quick request: For packaging Zope for Debian, I need to make it compliant to the FHS (Filesystem hierarchy standard). FHS requests that PID and socket files to into /var/run/, log files should go into /var/log/. While with the log files, I can call z2.py with something like "-l /var/log/zope/Z2.log", there's no such option for specifying the path for the ZServer pid file (-Z is only for zProcessManager.pid). Would this option be a reasonable addition to z2.py ? Should I file a bug in the Collector ? Gregor

2 2

Re: [Zope-dev] z2.py wishlist: Setting PID_FILE with command-line option
by Simon Michael 17 Aug '99

17 Aug '99

Anthony Pfrunder <s341625(a)student.uq.edu.au> writes: > Glad you are packaging for Debian - ditto - thank you.

1 0

RE: [Zope-dev] ZCatalog peculiarities?
by Phillip J. Eby 16 Aug '99

16 Aug '99

At 04:52 PM 8/16/99 -0400, Michel Pelletier wrote: > >A fix for this is checked in. useBrains is only called in the __init__, >__setstate__, addColumn and delColumn. The circular reference is >removed. This should be the correct behavior. The current brains >machinery is just a placeholder for the new brains machinery (probably >in 2.1), which will be based on what ZSQL methods do. In fact, they >will probably share the same code and have the added bonus of allowing >you to select a ZClass as a pluggable brain. This means you can >construct a ZClass that defines the objects that get returned by the >Catalog (or an SQL Method). This would be pretty cool. Indeed it would. And thanks for ending my confusion on these mystical Catalog matters. :)

1 0

Zope 2.0.0b4 README.txt
by Andreas Kostyrka 16 Aug '99

16 Aug '99

Hi! The README.txt still references BOBOPOS, which is no longer included. Andreas -- Andreas Kostyrka | andreas(a)mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA

1 0

RE: [Zope-dev] ZCatalog peculiarities?
by Michel Pelletier 16 Aug '99

16 Aug '99

> -----Original Message----- > From: Phillip J. Eby [mailto:pje@telecommunity.com] > Sent: Saturday, August 07, 1999 12:01 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] ZCatalog peculiarities? > > > First, in Catalog.py, it seems like virtually every method of > the Catalog > class calls self.useBrains(). useBrains() creates a new > class each time > it's called, and then deliberately creates a circular > reference in that > class, such that it can't be deleted. Finally, the logic of where > useBrains() is called, is such that it will be called once > for every item > retrieved from every search done on the catalog. Thus, every > record should > end up as an instance of a different class, specifically > created for that > record. This has me baffled, because I can't see why that would be > something useful. Am I missing something really deep here, > or is it just a > bug? It would seem to me that there should be something like > "_v_brains_inuse =_v_brains" at the end of the useBrains() > method, so that > at the beginning you can check for whether "brains is > _v_brains_inuse" and > skip creating a new class, etc. once the brains are initialized. A fix for this is checked in. useBrains is only called in the __init__, __setstate__, addColumn and delColumn. The circular reference is removed. This should be the correct behavior. The current brains machinery is just a placeholder for the new brains machinery (probably in 2.1), which will be based on what ZSQL methods do. In fact, they will probably share the same code and have the added bonus of allowing you to select a ZClass as a pluggable brain. This means you can construct a ZClass that defines the objects that get returned by the Catalog (or an SQL Method). This would be pretty cool. > > The next thing I've noticed, is that Catalog.py imports from > Query, but > then never actually uses anything from it. Oh, sure, there's > an orify() > function that does stuff, and a query_map local variable set up in > searchResults() that references orify, but query_map never > gets used. (And > ZCatalog.py makes up another copy of the same query_map > object and passes > it in, but that never gets used either.) I even dug down to > Index.py and > TextIndex.py to make sure query_map wasn't used down at that > level, and > then I realized that query_map wasn't part of the namespace > being passed > down there anyway. This all looks like some sort of > vestigial leftovers, > perhaps during porting from ZTables...? > I'm going to leave this for now, think of it as the Zope equivalent of an appendix. I don't know what will happen if I take it out, and it's not doing any damage or causing any memory leaks or slowdowns or anything. > The third thing I saw, is that there are lots of constructs > of the form: > > if something in somethingelse.keys(): > > where the object 'somethingelse' appears to have a perfectly > good has_key() > method available. Again, is there some sort of deep Zen > here, like trying > to force index pages to be loaded, or...? I mean, it seems > like this would > be much less efficient than just hitting the has_key() methods. > These have been fixed, and will be in the final. > Last, and definitely least, I notice that useBrains() uses a > loop to create > scopy, when "scopy=self.schema.copy()" would suffice. That > wouldn't be > anything worth 'fixing', except considering how often that code would > appear to be being called. > Fixed. -Michel

1 0

2nd of back-to-back communications with Zope hanging?
by Marc.Conley＠mapics.com 16 Aug '99

16 Aug '99

I am using 2.0.0b1. I am interested in whether or not anyone else is having a problem with two back-to-back communications with Zope hanging for a period of time but ultimately working? I am opening a URL on a Java client using UrlConnection which is requesting that Zope run an external method. The purpose of the external method is to create a folder and add a property to the folder. After I get the result back from the above external method, I immediately open another Url from the Java client which calls another external method which requests the information that was added (the folder's property). When I open these Url's back-to-back, I finally get the response I am looking for after about 30 seconds. If I put a 1/2 second delay before opening the 2nd Url, it eliminates the problem--I get the response immediately. But, this is a bandaid for some kind of problem. Can anyone explain what I am experiencing here--have you had similar problems? Or even better, is this something that has been fixed recently. Overall, 2.0.0b1 is stable, etc. for what I am doing, so I was trying to wait until the final general release 2.0 comes out to switch. Thanks for any help/tips/explanations you may have!

1 0

Zope transactions and DAs
by Ross J. Reedstrom 16 Aug '99

16 Aug '99

Hey Zopeists - I spent some time this weekend testing the ZPyGreSQLDA with Zope2 beta4. I seem to have it working reasonably well now, but there are two issues I want to take up with those with more experience on the guts of the new TM machinery than me (I guess that means DC folks, primarily). First, observed behavior: My test system: Linux 2.2.10 Zope 2.0.0b4 (Linux x86 binary release: i.e. with it's own python) Python 1.5.2 PostgreSQL 6.4.2 and 6.5.0 My tests consist of creating a ZPyGreSQL connection, and two Z SQL methods, one valid (it's: SELECT * FROM pg_tables) and one invalid (SELECT * FROM no_such_table). Then, with the backend db running with a moderate level of logging, I use the manage_test interfaces on the Z SQL objects, and follow what's going on in the PostgreSQL logs. First, on startup, Zope2 opens 2 connections to the backend DB. This seems to relate to the number of active threads, since in later tests, I got more and more connections being created. This is fine, except only one connection is killed when you close the Zope DB Connection object. The rest hang around until the Zope process exits. Is there something I'm supposed to do in the DA to manage the connection pool? Second, I'm not happy with how the TM machinery is interacting with my DA. At first, with a fresh connection, when I use a ZSQL method, what I see is that Zope calls the _begin(), query(), and _finish() methods in my DA. However, as soon as there's been an error on a given db connection (like calling a ZSQL method with syntax errors), Zope only calls query(). I handle the rollback of the backend inside the query method: is that correct? Is there some what to get Zope to keep using the _begin and _finish calls? Lastly, I'm seeing some hanging in the Zope process, which I'd normally attribute to me not knowing what I'm doing in my DA code, but may relate to the lockups others have been reporting. What I see is occasionally, when I hit the 'Submit Query' button in the manage_test interface, the HTTP request get sent, then nothing happens. If I hit it again, I get an immediate response. If I do this enough times, quickly enough, I sometimes get a new connection to the DB backend, which hangs around until Zope quits. Well, that's about it for now. If anyone wants to tryout my code, it's at http://wallace.ece.rice.edu/ZPyGreSQLDA-0.3-rjr2.tar.gz DC folk, you can also find it in the obvious place, where the ZDP people would look. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm(a)rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005

1 0

form action in specific context
by Martijn Faassen 16 Aug '99

16 Aug '99

Hi everybody, I'm trying to find the best way to describe this problem. I'm dealing with XML Document, but this could just occur if I have a folder subfolders and some documents inside. What I have is set of DTML methods that render the contents of an XML Document to an XML page. It does this by going into the XML tree (which you can see as a folder tree), and because through acquisition the right DTML method to render a specific element (or type of folder) is known at that element too, I simply call that method on that element to render. I do stuff somewhat like this: DTML Method render_foo: <h2><dtml-var title></h2> <dtml-with bar> <dtml-var render_bar> </dtml-with> DTML method render_bar: <form action="form_response"> .. </form> <p><dtml-var whateverproperty></p> Basically, I just call different render_* DTML methods on subtrees, which exist because of acquisition. This all works well, and my HTML gets rendered. But as you see, I included a form in render_bar. But then, on the rendered page, when I submit the form, what is called by the form is *not* a DTML method on the 'current' branch of the tree, but a DTML method at the folder where the XML document resides. This is understandable, but not what I want; I want to call a DTML method in the tree (that should be there because of acquisition), because otherwise the DTML method will not have the right context. In the example I'd like to call form_response in the context of the object that is rendered by render_bar. So somehow I will need to do something with this: <form action="????">. What should I put in the action attribute? An alternative would be to use hyperlinks, and a 'href'. But how do I know what URL to call? The 'URL' Zope variable isn't helpful, as it gives the URL of the root. I want the URL of the current object that is rendered. I'm afraid this all sounds terribly confusing. If so, please let me know and ask questions, so I can clarify. Regards, Martijn

1 2

Problem with distributing ZClasses
by Josh Zeidner 16 Aug '99

16 Aug '99

Has the distribution mechanism been tested for ZClasses? I am having trouble getting this product to work on other peoples systems. -Josh Z _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

2 1