[Zope-CMF] Re: Add forms and menus

[Charlie Clark]

Am 13.07.2008 um 20:21 schrieb Martin Aspeli:

> I doubt that formlib will be replaced by z3c.form. Rather, it just  
> seems that everyone prefers to work with the latter and so the  
> former is becoming less relevant.

I wonder who "everyone" is? When I asked Maartijn Faassen as  
Europython he didn't seem to be in a hurry to migrate Grok to using  
z3c.form and his work on Formulator was possibly the start of a Zope  
forms library of which formlib and z3c.form are the nth and n+1th  
generations.

> They are definitely different, and don't share any code as far as I  
> know, but if you know one, moving to the other is pretty trivial.  
> z3c.form also has good (if a bit too abundant) documentation.

I've only briefly looked at z3c.form but it seems to make abundant  
reference to how zope.formlib works.

> Thus, if CMF hasn't yet picked a form library in a release, then you  
> could try to learn from Plone's mistakes and not jump on a sinking  
> ship. :)

We're already using zope.formlib in the "experimental browser views"  
edit forms. The reference to a sinking ship is totally off-target. My  
own view is that sometimes it is better to wait for version 2 of a  
product or library to be released before adoption. Surely Plone has  
suffered from adopting some stuff too early?

>>> How about we use a naming convention that's linked to the factory   
>>> that's persisted in the FTI, i.e. we look for a view called "add-  
>>> <factory_name>" and link to that if it's available.
>> You might as well stick with actions if you're going to do that.  
>> I've  been experimenting with the following
>> portal_type = self.request.form.get('portal_type')
>> at = getToolByName(self.context, 'portal_actions')
>> actions = at.listFilteredActionsFor(self.context)
>> addable = actions.get('add', [])
>> for a in addable:
>>     if a['id'] == portal_type:
>> 	return request.response("%s/%s" (%self.context.absolute_url(),   
>> a['url']))
>> It's workable but so easy to break as it relies on "add" actions   
>> having the same name as the portal_type. It makes much more sense  
>> to  me to have this on the type info: if I ask the type tool for  
>> the  factory, surely I can also ask it for the view?
>
> You mean we have an action on the FTI object with category 'add' and  
> name == FTI name/portal_type? That still means having to get that  
> link right, though (a typo in the FTI name or a rename of the FTI  
> makes it break), and I question whether you ever need all the other  
> info that actions provide. We already have ways to control add  
> permissions and other filters for what's addable where.


Yes, which is why I don't favour this approach: it can work but is  
likely to cause problems.

What we all want is to be able to get the add view for a particular  
portal_type but we can't do this through QueryMultiAdapter because the  
view has to be registered on a container. Actions are unsuitable but  
provided Yuppie with a bootstrap to test the whole procedure and  
highlight the deficiencies. I'm afraid I don't understand the  
internals too well but isn't something like <cmf:registerAddView ...>  
or what we're after until the Zope 3 world comes up with "the right  
way to do this"?

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226