December 1999 - Zope-Dev

ZCatalog broken in CVS
by Sascha Matzke 14 Dec '99

14 Dec '99

Hello, just FYI... In the file UnTextIndex.py (1.17) is a reference to an undeclared variable (stop_word_dict). from Lexicon import stop_word_dict solves the NameError but I doubt it solves the problem... Sascha -- .-> Sascha Matzke - sascha(a)bespin.de - http://www.bespin.de -. | Das Kapital ist die Flamme, der Faschismus das Benzin | | Anarchist Academy | `-- On this earth for 24 years, 61 days <----------------'

1 0

Where can I find Zope 2.1.0 in RPMS?
by Clayton Miller 14 Dec '99

14 Dec '99

I have seen the notice about Zope 2.1.0. I would like to upgrade but when I follow the RPMS link, all I see is version 2.0.1. Where can I get the RPMS for Zope 2.1.0? Thanks, Clayton ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: [Zope] ANN: Python Methods 0.1.7 up and over to DC
by Evan Simpson 14 Dec '99

14 Dec '99

"Phillip J. Eby" wrote: > Did Ty or I ever send you the "isDocTemp=0" fix? No, I don't think so. What problems does the mistaken DocTemp-ness cause? > Setting "isDocTemp=0" in the PythonMethod class fixes this. Send me CVS access instructions and I'll be happy to make the change ;-) > At the risk of excessively critiquing such a young and exciting product, > may I suggest that some care be taken w/respect to namespace issues in > PythonMethods? That is, rather than adding things like "special_formats" > and using special names like "traverse_subpath", couldn't we use import > with a special module path? I was a bit uncomfortable with both of these. In the case of "traverse_subpath", it wasn't clear to me how to decide whether to allow (and capture) direct traversal otherwise. I couldn't use property settings, since PMs don't have those, and I was reluctant to simply leave traversal always turned on. "special_formats" is sheer laziness on my part, since the dict was sitting there, ripe to be popped into the namespace, and with invalid identifiers for keys. > (E.g. "from _Zope.special_formats import > html_quote".) Then, specials would not be a part of the common namespace. > > To be honest, I'd rather see "from _ import var1,var2,var3" used to get > acquired variables, or even "self.var1", etc., rather than just importing > everything automatically. The closer that PythonMethods can stay to being > "pure" Python, the better off the Zope will be from a teaching standpoint. > Avoiding DTML's promiscuous namespace habits would be a step in the right > direction. Definitely. One of the reasons that 'import' is still missing from PMs is that you *can* use attribute and subscript access on a passed-in self or _-namespace to get at the object hierarchy. Since acquisition/REQUEST search aren't performed on bare names like in DTML, I don't feel too bad about bloating __builtins__ a bit. Cheers, Evan @ 4-am

2 1

Help, I lost all with GenericFolder!?!?!?
by Clayton Miller 14 Dec '99

14 Dec '99

I was having some trouble using GenericFolder 1.0.1 to determining if the user had actually logged in. So, I shutdown Zope and untared GenericFolder 1.0.5. After chown-ing the files, editting the Makefile user, and running make install; my Zope management site continually gives me a Temporarily Unavailable error message. Please, does anyone have any suggestions? Thanks, Clayton ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: [Zope-dev] Re: [Zope] using CVS for Zope object stores?
by Anthony Baxter 14 Dec '99

14 Dec '99

>>> Anthony Baxter wrote > A thought I've had is that you could get a 'point in time' view with the > current FileStorage by simply stopping reading after X bytes - since the > file is just appended to, this will show the ZODB as it was at that state. Hm. Looking closer at the code, ZODB.FileStorage.FileStorage already supports this - there's a 'stop' option that should be a ZODB.TimeStamp.TimeStamp(). Exposing this is actually not that hard - you'd need to hook into Zope/__init__.py to pass the arguments through (and making sure you go into readonly mode, or else strangeness will result). Course, a pack operation's going to mess this around rather a lot. Anthony

1 0

Re: [Zope-dev] Re: [Zope] using CVS for Zope object stores?
by Anthony Baxter 14 Dec '99

14 Dec '99

>>> "Stuart 'Zen' Bishop" wrote > Point in time rollback > Possible to add hooks to allow viewing of previous revisions > of documents into Zope, perfect for Document Management > products. > Not only undo, but in theory it would be possible to support > branching and merging if Zope became intelligent enough > (loosly distributed databases anyone?) A thought I've had is that you could get a 'point in time' view with the current FileStorage by simply stopping reading after X bytes - since the file is just appended to, this will show the ZODB as it was at that state. >From the UML models, tho, the FileStorage doesn't write down a timestamp with each transaction - ah, but Mr SourceCode says that the transaction ID is a timestamp. Exceeellent. Sure, you'd want to make it a readonly view, but it could still allow some recovery for when someone's made a godawful screwup. Anthony

1 0

Re: [Zope] using CVS for Zope object stores?
by Stuart 'Zen' Bishop 14 Dec '99

14 Dec '99

[Redirected to zope-dev] On 13 Dec 1999, Guido A.J. Stevens wrote: > In short, we crave for a way to use cvs on Zope object stores. I've thought of two ways of doing this 'seemlessly', both involving writing a new Storage module for Zope. FSStorage - Store each non folderish object in an individual file in ascii pickle format For each folderish object, a directory is created and the actual ascii pickle data is stored in a 'magic' file in this directory. Caveats: If you use 'id' as the filename, ids will be restricted to those available on the underlying OS (including case issues), and there would need to be reserved id's (eg CVS, RCS, '__magic__'). Alternatives will give meaningless names (eg using a ascii representation of _p_oi). Undo would probably not be available Bonuses: May outperform existing FileStorage on certain hardware (eg. my NetApp 740) Allows integration with tools like CVS or RCS, although I have no idea if rollback could be done on individual objects. CVSStorage - As FSStorage, but store objects directly in a CVS repositary. Caveats: Speed. A fork tax would be required each time an object is read (to call the OS's cvs executable), unless someone wraps the CVS source into cvs.py (Might be easy with SWIG - I have no idea). Even without the fork tax, it will be slower accessing the object through CVS. And large memory caches don't help for writing objects... Bonuses: Point in time rollback Possible to add hooks to allow viewing of previous revisions of documents into Zope, perfect for Document Management products. Not only undo, but in theory it would be possible to support branching and merging if Zope became intelligent enough (loosly distributed databases anyone?) It might be worth using some variant of pickle that is more CVS friendly (ie. more linefeeds). > Has anybody been working on this? Has anybody come up with a more > intelligent approach than diffing and patching wholesale xml exports? > Do we need to wait for a different (non-monolithic) filestorage > backend - is anybody working on /that/? It doesn't exist yet, and I have plenty of other stuff to keep me busy at the moment.... -- ___ // Zen (alias Stuart Bishop) Work: zen(a)cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen(a)shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen

1 0

RE: [Zope-dev] Plain text version of HTTPRequest
by Michel Pelletier 13 Dec '99

13 Dec '99

> -----Original Message----- > From: Andrew M. Kuchling [mailto:akuchlin@mems-exchange.org] > Sent: Monday, December 13, 1999 4:51 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Plain text version of HTTPRequest > > > The __str__() method of HTTPRequest objects produce formatted HTML. > For the purposes of e-mailing tracebacks, I'd like a plain ASCII > version of the same information. If I added a method (say, .dump()) > that generated a plain text version, would it be accepted into the CVS > tree? I'm not sure where the formatted version of REQUEST objects came from, but Jim got this wild look in his eye when he found out about it, since you can just go to /REQUEST anywhere in a URL space in Zope and inspect the REQUEST object. I think your need is valid, perhaps though we should think about a different way? Is there is a need for __str__() on REQUEST? Should it be publicly visible? If not, then perhaps the HTML markup should be removed and it made to satisfy your needs. -Michel

2 1

RE: [Zope-dev] Re: [Zope] ANN: Python Methods 0.1.7 up and over t o DC
by Michel Pelletier 13 Dec '99

13 Dec '99

> -----Original Message----- > From: Itamar Shtull-Trauring [mailto:itamars@ibm.net] > Sent: Monday, December 13, 1999 4:48 PM > To: Phillip J. Eby > Cc: zope-dev(a)zope.org > Subject: [Zope-dev] Re: [Zope] ANN: Python Methods 0.1.7 up > and over to > DC > > > Moved to zope-dev. > > "Phillip J. Eby" wrote: > > > At the risk of excessively critiquing such a young and > exciting product, > > may I suggest that some care be taken w/respect to > namespace issues in > > PythonMethods? That is, rather than adding things like > "special_formats" > > and using special names like "traverse_subpath", couldn't > we use import > > with a special module path? (E.g. "from > _Zope.special_formats import > > html_quote".) Then, specials would not be a part of the > common namespace. > > This would be the only thing you can import in any case (no > imports in PM), > so how about just renaming traverse_subpath to _traverse_subpath and > special_formats to _special_formats? That way there's no chance of > namespace conflicts without adding an import. I agree with Phillip though, we are going down the route of DTML and straying from python by populating the namespace with assumed objects. -Michel

1 0

Re: [Zope] ANN: Python Methods 0.1.7 up and over to DC
by Itamar Shtull-Trauring 13 Dec '99

13 Dec '99

Moved to zope-dev. "Phillip J. Eby" wrote: > At the risk of excessively critiquing such a young and exciting product, > may I suggest that some care be taken w/respect to namespace issues in > PythonMethods? That is, rather than adding things like "special_formats" > and using special names like "traverse_subpath", couldn't we use import > with a special module path? (E.g. "from _Zope.special_formats import > html_quote".) Then, specials would not be a part of the common namespace. This would be the only thing you can import in any case (no imports in PM), so how about just renaming traverse_subpath to _traverse_subpath and special_formats to _special_formats? That way there's no chance of namespace conflicts without adding an import. -- Itamar S.T. itamars(a)ibm.net

2 1