April 2000 - Zope-Dev

Adding data attributes to a pluggable brain?
by Dr. Peer Griebel 11 Apr '00

11 Apr '00

Hi, I just started using pluggable brains. The first thing I observed is that changes to the brain class are only seen in Zope after a restart of Zope. This differs to the behaviour of external methods. For newbies this can be quite irritating. But now to my question: How can I add a data attribute to my brain? Whenever I try to say self.attr=42 in a method of the brain class I get an Attribute Error. I can use a construct like self.__dict__['attr']=42. This seems to work. But is it the right way? Thank you for your help! -- connection reset by Peer _______________________________________________________________________ Dr. Peer Griebel Tel. +49 7581 4831 23 Geschäftsführer Fax. +49 7581 4831 11 Knoll Informationssysteme GmbH http://www.knoll-is.de Dreiköniggasse 17 mailto:peer@knoll-is.de 88348 Saulgau privat: mailto:peer.griebel@gmx.de

1 0

Re: [Zope-dev] Problem in ZGadflyDA/__init__.py
by Tres Seaver 11 Apr '00

11 Apr '00

Gregor Hoffleit <flight(a)hoffleit.de> > To: Jim Fulton <jim(a)digicool.com>, zope-dev(a)zope.org > Subject: > > There's a small but sometimes fatal problem in ZGadflyDA/__init__.py: > > __init__.py currently checks for the presence of a gadfly directory in > Zope's var directory, and creates it if it's not yet there: > > j=os.path.join > d=j(j(INSTANCE_HOME,'var'),'gadfly') > if not os.path.exists(d): > os.mkdir(d) > os.mkdir(j(d,'demo')) > > Now if you start up z2.py as root, since __init__.py is called *before* > z2.py tries to setuid/setgid, the gadfly directory will be created with the > original uid and gid, i.e. root. > > Depending on the umask, this leaves the Zope process with insufficient > permissions to access the gadfly directory. > > The suggested change is easy: Similar code is already in ZGadflyDA/db.py, so > it should be safe to remove the lines above from ZGadflyDA/__init__.py. So that we don't lose it in the list, please submit this change as a "bug-with-patch" to the Collector: http://classic.zope.org:8080/Collector/developer_input Thanks! Tres. -- ========================================================= Tres Seaver tseaver(a)digicool.com tseaver(a)palladion.com

1 0

Actual objects in ZODB not visable to management screen or the Catalog
by Jason Spisak 10 Apr '00

10 Apr '00

This is seriously strange. I have not seen this before...ever. What would prevent and Zclass instance of meta_type 'ZGL_Client' that is viewable by the URL http://localhost:8080/955393378581117/955393587277964 To not be seen anywhere in the Management interface, or indexed by the Catalog using the 'Find Items' tab. Basically it doesn't exist anywhere that I can see, except to put in that URL. "Objects should appear in folder lists" is checked for both this object and it's parent object. The management interface shows nothing, and the Catalog only indexes it if I type in index_object after the URL and force it. And for the final kicker...the old "Find" tab shows that there are no 'ZGL_Client' meta_type in the ZODB. The instance reacts fine to all of the changes I make to the ZClass too. It is just invisible. Any ideas? -- Jason Spisak 444(a)hiretechs.com

1 0

TreeTag
by Chris Withers 10 Apr '00

10 Apr '00

<RANT> Now that's the collector has been opened up you can see that certain things have stagnated ;-) If you search for TreeTag, you get seven items. One is a patch fixing a problem I have (which is still there in 2.1.6), another is a patch fixing a problem I didn't know about, and one adds some really useful functionality. They are all between 4 and 8 months old and yet all except one are still 'pending' Even with DC's limited resources that's not very good... </RANT> There must be a better way, personally I'd like to know how I can help and get these patches into the next point release as quickly as possible. Any ideas? cheers, Chris PS: I was just about to go and fix these problems myself, so I'm very glad the collector has opened up ;-)

1 0

help: updating zclass-based products
by news-list.zope.dev＠innominate.de 10 Apr '00

10 Apr '00

Hi, we have a development server and a production server. I'm currently developing a zclass-only product. To install it on the production server, I make a zexp off my dev-machine and import it on the prodcution server. This works _once_, because if I try to import a new version of the same product zexp, I naturally get an error, as the product is already installed. I can delete the old version and re-import the new version of course but with my zclasses being some kind of static superclasses of their instances, what happens to these? Answer: as long as the zope process is running between deleting the old version and importing the new one, everything's fine. But if zope dies for some reason, all my instances are gone !? So: how do YOU update zclass-based products between a development and a production server? Can it be that there's no intelligent mechanism for that? Am I just too stupid? Thanks, Heiko -- heiko.stoermer(a)innominate.de innominate AG networkingpeople fon: +49.30.308806-0 fax: -77 web: http://innominate.de

2 1

volatile state maintenance
by Sam Gendler 10 Apr '00

10 Apr '00

I have a product which needs to maintain a connection to a 300MB database file (Metakt, if you must know). The initial connection takees about 3 seconds, due to the size of the file, so I wanted to make a product that will keep the connection open, and re-use it. I made a python base class which opens the connection, but I get the following error from zope when it tries to pickle the object into the ZODB. Traceback (innermost last): File /home/ultraseek/Zope-2.1.6-src/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /home/ultraseek/Zope-2.1.6-src/lib/python/ZPublisher/Publish.py, line 179, in publish File /home/ultraseek/Zope-2.1.6-src/lib/python/Zope/__init__.py, line 202, in zpublisher_exception_hook (Object: RoleManager) File /home/ultraseek/Zope-2.1.6-src/lib/python/ZPublisher/Publish.py, line 169, in publish File /home/ultraseek/Zope-2.1.6-src/lib/python/ZODB/Transaction.py, line 237, in commit File /home/ultraseek/Zope-2.1.6-src/lib/python/ZODB/Connection.py, line 325, in commit (Info: (('*yr88KIATmOLZfiZXPxWNeA==', 'ODP'), '\000\000\000\000\000\000\000\262', '')) UnpickleableError: (see above) I don't actually need the database connection itself to be in the ZODB, as it will not be open the next time zope restarts, anyway, but I would like it to remain resident in memory so that I can use it without reconnecting on every request. Additonally, it would be gat to be able to detect when the connection has gone down, and re-create it. Any tips? I am sure it can be done, but I have no idea where to even start, as far as adding something to the global namespace --sam

5 8

Logout
by Sin Hang Kin 10 Apr '00

10 Apr '00

I just apply an test account from imeme.net. I suddently realize that There is no logout operation available. Rgs, Kent Sin

5 5

Re: Zope-Dev Logout
by Sin Hang Kin 09 Apr '00

09 Apr '00

With a login operation beening done, and the server seems to accept this. The user from his pass experience, would expect an logout operation when he finish his work. >From an interface design or psyc. point of view, the logout operation is necessary. Even it is 100% safe, without a logout operation, the user never feel safe. Even, it does not do anything, put in an logout link to save the user from a possible nightmare. Rgs, Kent Sin

1 0

programmer-only ZopeFish release...
by David Brown 09 Apr '00

09 Apr '00

I've been working on creating an environment for Zope that mirrors some fo the functionality of Manila (http://manila.userland.com) What I've been concentrating on is the ability to edit and post through Pike (http://pikebeta.userland.com) a cool outlining tool. The functionality is minimal right now. VERY minimal. But I wanted to get it out in the world and see if I could get some momentum going. I'm tracking its development at http://zopefish.weblogs.com and you can download it at http://zopefish.weblogs.com/ZopeFishRelease Come on in and join the fun. dave

1 0

dtml-call problem
by Dr. Peer Griebel 08 Apr '00

08 Apr '00

Hi, I think there is a problem in Zope: I have 3 methods: method_a: <dtml-call "method_b"> method_b: <dtml-call "method_c"> method_c: <dtml-return "_.int(1)"> I can call method_a without problems. But if I change it from <dtml-call "method_b"> to <dtml-call "method_b()"> (look at the braces!) I get an error message. I think this is an error in Zope. Can anybody verify this?! I tried to use such a construct in a larger system here. Error Type: NameError Error Value: method_c Traceback (innermost last): File D:\Programme\uZope\lib\python\ZPublisher\Publish.py, line 214, in publish_module File D:\Programme\uZope\lib\python\ZPublisher\Publish.py, line 179, in publish File D:\Programme\uZope\lib\python\Zope\__init__.py, line 202, in zpublisher_exception_hook (Object: ElementWithAttributes) File D:\Programme\uZope\lib\python\ZPublisher\Publish.py, line 165, in publish File D:\Programme\uZope\lib\python\ZPublisher\mapply.py, line 160, in mapply (Object: method_a) File D:\Programme\uZope\lib\python\ZPublisher\Publish.py, line 102, in call_object (Object: method_a) File D:\Programme\uZope\lib\python\OFS\DTMLMethod.py, line 145, in __call__ (Object: method_a) File D:\Programme\uZope\lib\python\DocumentTemplate\DT_String.py, line 502, in __call__ (Object: method_a) File D:\Programme\uZope\lib\python\DocumentTemplate\DT_Util.py, line 335, in eval (Object: method_b()) (Info: method_b) File <string>, line 0, in ? File D:\Programme\uZope\lib\python\OFS\DTMLMethod.py, line 141, in __call__ (Object: method_b) File D:\Programme\uZope\lib\python\DocumentTemplate\DT_String.py, line 502, in __call__ (Object: method_b) File D:\Programme\uZope\lib\python\DocumentTemplate\DT_Util.py, line 335, in eval (Object: method_c) (Info: method_c) File <string>, line 0, in ? NameError: (see above) -- connection reset by Peer _______________________________________________________________________ Dr. Peer Griebel Tel. +49 7581 4831 23 Geschäftsführer Fax. +49 7581 4831 11 Knoll Informationssysteme GmbH http://www.knoll-is.de Dreiköniggasse 17 mailto:peer@knoll-is.de 88348 Saulgau privat: mailto:peer.griebel@gmx.de

4 4