Re: [Zope3-Users] Re: execution time of a request?
On Sat, Apr 07, 2007 at 01:21:39PM +0200, Jürgen Kartnaller wrote: By the way, marius, thanks for your great profiling library. That's a bit misleading. The profiling library resides in the Python standard library, I just wrote a convenient decorator for it (mostly because I could never remember how to use the profile/hotshot modules). http://mg.pov.lt/blog/profiling.html Speaking of which, has anybody ever succeeded in profiling Zope 3 unit tests? I get an exception at the very end, and no useful results. Marius Gedminas -- One picture is worth 128K words. signature.asc Description: Digital signature ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: execution time of a request?
Marius Gedminas a écrit : On Sat, Apr 07, 2007 at 01:21:39PM +0200, Jürgen Kartnaller wrote: By the way, marius, thanks for your great profiling library. That's a bit misleading. The profiling library resides in the Python standard library, I just wrote a convenient decorator for it (mostly because I could never remember how to use the profile/hotshot modules). http://mg.pov.lt/blog/profiling.html Speaking of which, has anybody ever succeeded in profiling Zope 3 unit tests? I get an exception at the very end, and no useful results. Not unit tests, but I've tried to profile some functions, like __call__ or ViewPageTemplateFile, and I always end up with errors. Either __call__ has a missing parameter, or the function has no __name__, or nothing at all. Christophe Marius Gedminas ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] EditForm fails in SiteManager because of containment constraint
Am Samstag, 7. April 2007 18:06 schrieb Christophe Combelles: Hello, I have a regular content object which uses the formlib for its edit view. Nothing special, just like a Recipe. But I want this object to only reside in the Site Manager, because it will be used as a configurable local utility (some kind of LocalKitchenTools utility) Everything is perfect, and the EditForm works well until I want to tell this object to be only contained in the SiteManager. So I just add this statement in the interface: containers(ILocalSiteManager) or containers(ISiteManagementFolder) When I do any of these, the EditForm fails with a ComponentLookupError What Am I missing? Why does a simple constraint create an error on this? I *think* I've got the same problem - the thing is that interfaces inheriting from container interfaces inherit the __name__ and __parent__ attributes. And the formlib classes try to set up widgets for these attributes, which results in a component lookup error. I simply omitted these two attributes, which solved the problem. Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Re: EditForm fails in SiteManager because of containment constraint
Am Samstag, 7. April 2007 18:43 schrieb Christophe Combelles: Jürgen Kartnaller a écrit : Christophe Combelles wrote: Hello, I have a regular content object which uses the formlib for its edit view. Nothing special, just like a Recipe. But I want this object to only reside in the Site Manager, because it will be used as a configurable local utility (some kind of LocalKitchenTools utility) Everything is perfect, and the EditForm works well until I want to tell this object to be only contained in the SiteManager. So I just add this statement in the interface: containers(ILocalSiteManager) or containers(ISiteManagementFolder) 'container' adds __parent__ as schema.Field attribute to your interface. You need to omit __parent__ in your formlib form_fields definition. thanks, that's it, so I will omit only __parent__ You had already answered while I was still writing my previous post :) Couldn't this thing be managed by the formlib itself? The error is not explicit and does not mention __parent__ anywhere Yes, this was also my problem - the error message was quite cryptic and it took me hours to find out the reason. A good solution would be to either making the error message more verbose, or to automatically omit such attributes in the formlib (which could also lead to other problems). Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: RFC 4122 UUIDs
Fred Drake wrote: On 4/6/07, Philipp von Weitershausen [EMAIL PROTECTED] wrote: How is there a ZCML pain? Simply register the adapter for all IAnnotatable objects. Typically your content objects are annotatable anyway because you want DublinCore stuff etc. This sounds like this will result in huge numbers of UUIDs being generated for objects that aren't syndicatable content in this application. The subscriber should probably be registered for objects that can be syndicated, not everything, to avoid useless CPU load and database bloat. Of course, as the OP suggested there's already an annotation for syndication-related information, I'd just add it to that, and not use a separate annotation. Another common pattern is to invent a new marker interface, e.g. IUUIDAware, which perhaps inherits from IAnnotatable so that it's clear there are annotations involved. Then you register adapters from that, and use a generic ZCML statement to give various objects this marker. In a CMF world, for example, we may do: class class=Products.CMFCore.DynamicType.DynamicType implements interface=.interfaces.IUUIDAware / /class Martin ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: EditForm fails in SiteManager because of containment constraint
Hermann Himmelbauer wrote: Am Samstag, 7. April 2007 18:43 schrieb Christophe Combelles: Jürgen Kartnaller a écrit : Christophe Combelles wrote: Hello, I have a regular content object which uses the formlib for its edit view. Nothing special, just like a Recipe. But I want this object to only reside in the Site Manager, because it will be used as a configurable local utility (some kind of LocalKitchenTools utility) Everything is perfect, and the EditForm works well until I want to tell this object to be only contained in the SiteManager. So I just add this statement in the interface: containers(ILocalSiteManager) or containers(ISiteManagementFolder) 'container' adds __parent__ as schema.Field attribute to your interface. You need to omit __parent__ in your formlib form_fields definition. thanks, that's it, so I will omit only __parent__ You had already answered while I was still writing my previous post :) Couldn't this thing be managed by the formlib itself? The error is not explicit and does not mention __parent__ anywhere Yes, this was also my problem - the error message was quite cryptic and it took me hours to find out the reason. A good solution would be to either making the error message more verbose, or to automatically omit such attributes in the formlib (which could also lead to other problems). -1 on automatic exclusion, that would be a bit magical. +1 on making the error message more verbose. It shouldn't be a lot of work to adjust the setUpWidgets and setUpEditWidgets functions in zope.formlib.form to make queryMultiAdapter() calls instead of getMultiAdapter(). Then in case of a None return value (i.e. there's no widget), raise a WidgetLookupError (a subclass of LookupError) with a proper error message. This is a small enough task that would make an excellent first contribution to Zope 3... any takers? :) Steps you'd need to take: * Become a Zope contributor by signing and mailing http://dev.zope.org/CVS/Contributor.pdf * Write a test that exercises the desired behaviour, best by extending the zope.formlib/form.txt doctest. (We require automated tests for all modifications, especially for bugfixes and new features). * Fix up zope.formlib.form to pass the test, in other words, introduce WidgetLookupError and raise it in the appropriate places. * Check in the modifications. All that should be done against the Zope 3 trunk. All in all it shouldn't take you more than half a day if you aren't familiar with Zope's source code yet, and it would open the door for future contributions. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
