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
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
