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 Clark
Helmholtzstr. 20
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to