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?


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.


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.


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to