Re: [Zope3-Users] Re: EditForm fails in SiteManager because of containment constraint
Philipp von Weitershausen a écrit : 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? :) I will try to see if I feel able to do such a thing, but apart from that, there is another good reason I would want to apply for a commiter account : I would like to review and complete french translations. I've already contributed l10n of several projects (gettext, ardour, dvdrip, dolibarr, etc.), and I've seen several typos, at least in the apidoc. Christophe 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. ___ 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
On 9 Apr 2007, at 13:08 , Hermann Himmelbauer wrote: This is a small enough task that would make an excellent first contribution to Zope 3... any takers? :) Certainly interesting, but I'm still very new to Zope 3, so I'm unsure if I am qualified for this task. Everybody has to start at some point :). What if I check in code that accidentally breaks something? The chances of that happening are low if you follow the guidelines: always write tests for modifications and always run *all* tests before checking in. We have automated tests for exactly this reason: avoiding accidental breakage. Also, the checkin police will be there to let you know when you screw up :). * 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). This once again raises the question for me how I execute such tests (such as form.txt) - is there some magical Zope 3 command? Executing these tests via debugzope does not always work, probably something has to be set up beforehand? Yes, most test require setup which we typically don't put in the text file because it would be confusing. I suggest you read up on unittests and doctests in particular (form.txt is a doctest). My book (http://worldcookery.com) devotes a whole chapter to automated testing. Note that re-playing doctests in the debugzope prompt is not an actual *automated* test. The idea of automated tests is that thousands of them can be run automatically with one command. Only that way we can ensure that modifications in one place won't break other code somewhere else: we always run that other code's tests! When having Zope 3 installed from a tarball, you can run its tests using a command like this: [EMAIL PROTECTED]:~$ /usr/local/Zope-3.3.1/bin/zopetest -p Running unit tests: Running: 1024/8148 (12.6%) ... When in a Zope 3 checkout, you simply execute python test.py - p (the -p flag switches on the percent display). Philipp ___ 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: 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
[Zope3-Users] Re: EditForm fails in SiteManager because of containment constraint
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. Jürgen ___ 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
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 Christophe Jürgen ___ 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
