August 1999 - Zope-Dev

Re: [Zope-dev] Something doesn't seem quite right with CopySupport.py/Moniker.py
by Kevin Dangoor 18 Aug '99

18 Aug '99

-----Original Message----- From: Brian Lloyd <Brian(a)digicool.com> To: 'Kevin Dangoor' <kid(a)kendermedia.com>; zope-dev(a)zope.org <zope-dev(a)zope.org> Date: Tuesday, August 17, 1999 9:21 PM Subject: RE: [Zope-dev] Something doesn't seem quite right with CopySupport.py/Moniker.py >> 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... > >Kevin, > >I _think_ the problem is that the copy/paste machinery >really needs to be called with a REQUEST so that it can >verify whether the copy is allowed. Try this and let me >know if you still have problems: > > def candp(fobj, tobj, REQUEST): > "Copy and paste" > > ids = fobj.objectIds() > if not ids: > return > cdata = fobj.manage_copyObjects(ids) > tobj.manage_pasteObjects(cdata, REQUEST) I made these changes, and modified my DTML to be: <dtml-call "candp(fobj, this(), REQUEST)"> I'm getting the same error (one or more items not found). Here's the end of the traceback... File C:\Program Files\Byproducts\lib\python\DocumentTemplate\DT_Util.py, line 315, in eval (Object: candp(fobj, this(), REQUEST)) File <string>, line 0, in ? File C:\Program Files\Byproducts\lib\python\Products\ExternalMethod\ExternalMethod.py, line 246, in __call__ (Object: candp) (Info: ((<Folder instance at 0168AF70>, <KMArticle instance at 01747F30>, [big REQUEST object deleted] File C:\Program Files\Byproducts\Extensions\art.py, line 28, in candp (Object: ElementWithAttributes) File C:\Program Files\Byproducts\lib\python\OFS\CopySupport.py, line 198, in manage_pasteObjects (Object: CatalogAware) Copy Error: (see above) Anything else to try? Kevin

1 0

Multimedia problems.
by EduDesign＠aol.com 18 Aug '99

18 Aug '99

Why is it that whenever I access a zope web page with a multimedia attachment that everything crashes. Does anybody understand this. If you'd like to crash my server, just access my site: http://psyche.ed.vt.edu:8080/workshop/Karl/Resume/TrooperH.htm If you have any ideas as to what is happening, drop me a line at EduDesign(a)aol.com Teresa Kimmel

1 0

RE: [Zope-dev] Something doesn't seem quite right with CopySuppor t.py/Moniker.py
by Brian Lloyd 18 Aug '99

18 Aug '99

> 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) > ... > > 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 Kevin, I _think_ the problem is that the copy/paste machinery really needs to be called with a REQUEST so that it can verify whether the copy is allowed. Try this and let me know if you still have problems: def candp(fobj, tobj, REQUEST): "Copy and paste" ids = fobj.objectIds() if not ids: return cdata = fobj.manage_copyObjects(ids) tobj.manage_pasteObjects(cdata, REQUEST) Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

the right way to do wiki in zope ?
by Simon Michael 18 Aug '99

18 Aug '99

Michel Pelletier <michel(a)digicool.com> writes: > I think that it would be a rather easy Zope application to clone. In > fact, it could be done with ZClasses and some clever DTML. Whose gonna > take a stab at it? I'm poking at it. I'll continue, though anyone should feel free to jump in and code it up. I'm not yet clear on the right way to do this. To begin, I imagine a bunch of DTML/structuredtext pages in a zope folder. The page render method would convert each WikiStyleHyperLink to either a navigation or page creation link, depending on whether that page exists. I've been considering: 1. add new ZWiki Document & Method classes - ideally these are like Formatted Document with WikiHyperlinks added. 2. add some wiki-enabled formats to the Formatted Document class - structured text + wiki, HTML + wiki, ascii + wiki But it's probably 3. something much more elegant using the new (to me) class features Comments, suggestions ?

2 1

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