[Zope3-Users] Re: EditForm fails in SiteManager because of containment constraint

Christophe Combelles ccomb at free.fr
Mon Apr 9 04:38:51 EDT 2007


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.
> 
> 



More information about the Zope3-users mailing list