- Zope-Dev - Zope lists

bad bare except in PageTemplateFile.py
by Steve Alexander 19 Jul '02

19 Jul '02

lib/python/Products/PageTemplateFile.py, line 110, method _cook_check try: mtime=os.stat(self.filename)[8] except: mtime=0 I've just spent an hour or so tracking down an awkward bug in some unit-tests. The true error was being hidden by this bare except. I'd change it, and commit the change, except that I don't know what it is supposed to be catching. Any hints? Actually, I'd rather just remove the try: except: and let os.stat fail if it is going to fail. Any objections? (of course there will be... even bare excepts were put there for some reason...) -- Steve Alexander

4 8

Fw: [Zope-dev] Nesting Forms
by Adrian Hungate 19 Jul '02

19 Jul '02

Ooops, I meant this to go to the list as well... Adrian... ----- Original Message ----- From: "Adrian Hungate" <adrian(a)haqa.co.uk> To: "Ross Boylan" <RossBoylan(a)stanfordalumni.org> Sent: Friday, July 19, 2002 8:40 AM Subject: Re: [Zope-dev] Nesting Forms > Although I would probably avoid what you are trying to do, it doesn't seem > that hard. Here is how I would do it (Which I think is just an extension of > the other sugestions here). > > Have one base class which contains (For example class _base) > * a method to produce an empty, or almost empty, page - All classes will > override this. > * a DTML Method which contains "header", "form start", a call to the method > above, "form buttons", "form end", "footer". No classes will override this. > > Then each desendant class would work something like (e.g. class A(_base) ) > * Override the method, get the HTML returned by _base.method() and add your > new HTML to it. > * Do not override the DTML Method.... > > All descendants of A could do the same by adding their own HTML onto the end > of A.method() etc... > > This should work (And could be repeated for as many screens as there are in > the product), because the <head></head>, <body></body> and <form></form> > elements are NOT part of the HTML returned by the base class method, so the > ordering should be correct. > > Of course, you will need to do the same with the form handler functions, but > that is basic python, and all products do that without thinking. > > I hope this is clearer to you than it is to me now I am re-reading it. :) > > Adrian... > > -- > Adrian Hungate > EMail: adrian(a)haqa.co.uk > Web: http://www.haqa.co.uk > > ----- Original Message ----- > From: "Ross Boylan" <RossBoylan(a)stanfordalumni.org> > To: "Dieter Maurer" <dieter(a)handshake.de> > Cc: "Ross Boylan" <RossBoylan(a)stanfordalumni.org>; <zope-dev(a)zope.org> > Sent: Friday, July 19, 2002 6:38 AM > Subject: Re: [Zope-dev] Nesting Forms > > > > On Thu, Jul 18, 2002 at 08:41:02PM +0200, Dieter Maurer wrote: > > > Ross Boylan writes: > > > > ... > > > > I would prefer a more elegant approach. Perhaps I can define some > > > > method in A that the dtml will reference, and then B can override the > > > > method to add some extra stuff (the method would return a DTML > > > > snippet). > > > That sounds good. It is how the ZMI works... > > > > ZMI = Zope Management Interface (i.e., in the core app), or is this > > something else? At any rate, I'm not sure what you're referring to, > > or where to look. > > > > > > > > > First, I'm not exactly sure how to pick up the method from the DTML. > > > There are two cases: > > > > > > * view of an existing object > > > > > > then the object is the client of the primary view. > > > Make all you snippets attributes of the object > > > and you can simply access them by name. > > > > > > The ZMI does this. If necessary, look how it does. > > > > The problem isn't just accessing them, but combining them. Say C is a > > subclass of B is a subclass of A. Each subclass has the entire user > > interface of its base class (aka superclass) and some extra stuff. > > > > Either each class implements its novel stuff with a unique name. In > > that case, I still have to make a separate dtml file for each, > > referencing the appropriate names (though your suggestion below helps > > on that). > > > > Or each has the same name. Then the problem is how to get the > > subclasses method to return its unique stuff plus everything in its > > base class. For vanilla methods that's not a big deal, but if each is > > a DTMLFile, I don't think it will work. More about that at the very > > bottom. > > > > > > > > * object creation form > > > > > > That's much more difficult. ZMI does not reuse fragments for > > > this case. > > > > > > There is a partial solution for DTMLFiles, but it is not nice > > > and restricted to DTML. > > > > > > "DTMLFile" constructors accept a dictionary with default > > > name bindings. This way, you can customize your > > > DTMLFile with different bindings according to context, > > > e.g. > > > > > > addAForm= DTMLFile('dtml/addForm', globals(), > > > comp1= AComp1 > > > comp2= AComp2 > > > ...) > > > addBForm= DTMLFile('dtml/addForm', globals(), > > > comp1= BComp1 > > > comp2= BComp2 > > > ...) > > > > This suggests one semi-refined strategy: the file defines the maximal > > interface, and then parts of it are guarded by <dtml-if ... > tests on > these > > extra variables I pass in. I could even pass the class in, but I > > suppose if I try to do issubclass(PassedInClass, MyApplicationClass) > > in the dtml-if I will find that I lack security to access > > PassedInClass, issubclass, or MyApplicationClass. > > > > > > > > > > > Second, I'm not sure if this is the best solution. For one thing, I > > > > would prefer to keep all my dtml in separate files, rather than > > > > defining it into my methods. > > > You can have separate files and do something like: > > > > > > class YourProduct: > > > .... > > > mySnippet= DTMLFile('dtml/mySnippetFile',globals()) > > > .... > > > > > > > The problem comes if I stick the different interface segments in > > different files, so A.dtml has the user interface for A and B.dtml has > > just the added interface for B, a subclass of A. But I want the user > > interface for B to be the combination of the A and B parts. > > > > > > > > Dieter > > > > > > > > > _______________________________________________ > > Zope-Dev maillist - Zope-Dev(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope-dev > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope ) > > >

1 0

adding custom products programmatically
by Kaimar Karu 19 Jul '02

19 Jul '02

Hi, I created a new Product, "GalahadFile" and in it I created several Z Classes, GalahadImageFile for example. Now if i want to use python script to add a GalahadImageFile programmatically - what should I do? I add Image files this way: context.galahad.file_storage[str(org_id)].manage_addImage(str(new_id), file=new_contents, title=new_title) and I want to add GalahadImageFiles this way: context.galahad.file_storage[str(org_id)].manage_addGalahadImageFile(str(new_id), file=new_contents, title=new_title) What should I do for this? What methods should I add and where for this "manage_addGalahadImageFile" to work? TIA, Kaimar

1 0

Re: [Zope-dev] Confusing segfault for Zope2 head on RH7.3
by Dieter Maurer 18 Jul '02

18 Jul '02

Barry A. Warsaw writes: > .... > At the PyErr_SetString() call > PyExc_IndexError is a perfectly valid PyObject*, but just one stack > frame later, inside the PyErr_SetString, the exception object is a > completely bogus address. PyErr_SetString() is not getting the same > object that Splitter_item() is providing in the first argument. Note > that the second argument, a char* is just fine. This looks like a compiler error, maybe an error in the dynamic linking code. I would single step through the assembler code and check whether the parameter is pushed onto the stack, whether this stack address is overwritten during the call sequence (which may include dynamic linking code) and whether the variable is referenced in "PyErr_SetString" from the correct frame offset. To do this, you would use "display/i $pc" and then single step on assembly level "xi" until you are beyond the setup code of "PyErr_SetString". You should find the frame offsets of you parameters with "i addr <parameter>". When you like, you can send me the output for further examination. Dieter

2 1

add new base classes dynamically with hotfixes
by Yuppie 18 Jul '02

18 Jul '02

Hi! I want to modify existing Zope classes without touching the code of the product packages. This how-to seems to fit exactly my needs: http://www.zope.org/Members/Caseman/Dynamic_Hotfix But one thing I don't know how to do: > 1. Add new base classes to existing classes, such as CatalogAware (use > the __bases__ attribute). It works with (classic) Classes, as described here: http://www.linuxjournal.com/article.php?sid=4540 But Zope uses also ExtensionClasses. The __bases__ attribute of ExtensionClasses appears to be read-only and ExtensionClass is a run-out model (see http://mail.python.org/pipermail/python-dev/2001-December/018807.html ). So what I'm looking for, is a work-around. Any ideas? Thanks! Yuppie

1 0

Zope+java applet
by Juliette Colmant 18 Jul '02

18 Jul '02

Hi, I wanted to know if it was possible to call a java applet with Zope? What kind of object do I have to use? When shall I put the file of my java Applet? Does someone have a little example? Thanks, Juliette. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Leak in 2.5.1 cAccessControl.c !?
by Stefan H. Holek 18 Jul '02

18 Jul '02

Hi All! I believe I have found a leak in cAccessControl.c of Zope 2.5.1. See the patch below. It was difficult to spot because in the respective section of cAccessControl.c the 'owner' variable is reused several times. Note that 'ASSIGN' decrefs 'owner' before actually assigning, whereas the original line doesn't and thus leaks a ref (I think). I was hunting for leaked ImplicitAcquirerWrappers and was able to track them down to Owned.getOwner() which returns wrapped User objects (LeakFinder rocks!). The patch appears to stop the wrappers from leaking. However, I am still leaking Users so I am not sure whether I have really and completely nailed it. From what I have seen in Acquisition.c decref'ing a wrapper also decrefs the wrappee. Assuming that no special handling of wrapped vs. unwrapped objects is required (with regards to decref'ing) what I observe may well be unrelated. What do you think? If somebody can confirm this I will put it in the Collector. Thanks, Stefan --- cAccessControl.c Fri Apr 12 17:18:44 2002 +++ cAccessControl.c Thu Jul 18 13:22:48 2002 @@ -1028,7 +1028,7 @@ } if (owner != Py_None) { - owner = PyObject_GetAttr(owner, allowed_str); + ASSIGN(owner, PyObject_GetAttr(owner, allowed_str)); if (owner) ASSIGN(owner, callfunction2(owner, value, roles)); if (owner == NULL) -- Those who write software only for pay should go hurt some other field. /Erik Naggum/

1 0

Zope 2.4.3 & patched Python 2.1.3 @ FreeBSD crashing
by Myroslav Opyr 17 Jul '02

17 Jul '02

Hi, In past times I was advised to apply a patch and increase stack size for pthreads of FreeBSD. I did and it helped for Zope 2.5.0 & CMF 1.2 + PageTemplates. It was moderately stable situation but it appears to crash again. For other site (with other Zope version)... Zope Version (Zope 2.4.3 (source release, python 2.1, linux2), python 2.1.3, freebsd4) Python Version 2.1.3 (#4, May 15 2002, 17:31:48) [GCC 2.95.3 20010315 (release) [FreeBSD]] System Platform freebsd4 If portions (PT) of a web-page are rendered everything is ok. Management screens either has no problems. But rendering a compound PT-based page makes Zope crash with assertion "STACK_LEVEL() <= f->f_stacksize" failed: file "Python/ceval.c", line 695 on console. What is suggested solution? Increase pthreads stacksize? it was THREAD_STACK_SIZE=0x20000 as advised... Thanks, m. -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav(a)zope.net.ua <mailto:myroslav@zope.net.ua> cell: +380 50.3174578

2 2

Segregation of the Zope2 and Zope3 checkins implemented
by Ken Manheimer 17 Jul '02

17 Jul '02

I've just committed the change to the file that dictates checkin notice routing so that Zope3 checkins are directed to the zope3-checkins(a)zope.org mailling list, instead of being included in the zope-checkins(a)zope.org list. For those of you on the latter list interested in continuing to get zope3 checkins, subscribe to the zope3-checkins list at: http://lists.zope.org/mailman/listinfo/zope3-checkins Happy hacking! -- Ken klm(a)zope.com

1 0

Restricted Compiler issues on FreeBSD? (Core Dumps...waaa!)
by Jeffrey P Shell 17 Jul '02

17 Jul '02

For a while now, Tracker has been core dumping on my with Zope 2.5.1 with both Python 2.1.2 and 2.1.3 on FreeBSD 4.5 (Intel). The culprit seems to be expressions that are heavy on parenthesis. For example, the following works:  But it core dumps when changed to:  Don't ask me what this expression does - I just kept whittling at it until the crashes stopped. Then I went and found quite a few others. I made a lot of fixes by turning complex expressions into many smaller ones inside a single 'let' tag. Does anyone know other possible fixes for this issue? Is there some Python stack size setting I can set at compile time? I have some other code that has not survived the move to Zope 2.5.x/Python 2.1.x/FreeBSD. FWIW, the Python 2.1.2 used was from the BSD Ports, while the 2.1.3 was compiled by hand. -- Jeffrey P Shell www.cuemedia.com

4 3