[Zope-CMF] Re: Add forms and menus

[Martin Aspeli]

Charlie Clark wrote:
> 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.

Well, let me put it another way then: A lot of people have expressed 
dissatisfaction with formlib and seem to like z3c.form better.

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

Right. z3c.form is an attempt to rectify some of the mistakes from 
zope.formlib and build something better.

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

*shrug*

Do what you please. I'm not particularly wedded to one or the other. But 
having used both, I'm pretty sure that z3c.form is a better library. In 
many ways, z3c.form *is* version 2 of formlib.

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

I don't have "an approach", I'm trying to find one that works. I'm not 
sure what problems you're referring to, though.

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

Mmmm... I'm not sure I follow here. The issue is how to render the 
correct link to the add view for each addable type. You loop through the 
addable types and then render a list of links. If by queryMultiAdapter 
you mean the browser view lookup, then that's something the publisher 
does when someone clicks the link, not something we'd do to find out 
what those links are.

> Actions are unsuitable but  
> provided Yuppie with a bootstrap to test the whole procedure and  
> highlight the deficiencies.

Obviously.

> 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"?

Zope 3 has a way, it's called <browser:addMenuItem /> (or something like 
that). However, Tres and Yuppie have pointed out reasons why doing this 
with global component registrations is not ideal.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book