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