Tres Seaver wrote:
> yuppie wrote:
>> 1.) look up add view actions in a different way
>> The current implementation is not flexible enough. There is no way to
>> sort or group these actions.
>> This is on my todo list, but I still have to write a proposal.
> Hmm, I don't recall the issue here.
There wasn't much discussion about this.
Some time ago Dieter asked for grouping support:
And I am missing a way to control the order of the add actions.
The latter could be resolved by making the types tool an ordered
container. But I tend to use special IActionCategory objects in the
actions tool instead. They would look up the add actions in the types
tool and provide features like filtering and sorting.
The current mechanism was never released, so I'd rather change that now
than after a release.
>> We also should decide when to switch from zope.formlib to z3c.form. I
>> have no ambitions to maintain zope.formlib based code for a long time.
>> If we make Zope 2.12 the required platform for CMF 2.2 we can easily add
>> z3c.form to the dependencies and refactor existing forms.
> I'm actually uncomfortable with either dependency.
>> Or we could
>> move the forms and other views to a separate package. That way
>> CMFDefault would not depend on zope.formlib nor on z3c.form.
> I would favor the latter. cmf.forms, maybe?
Don't know. I don't think we have the resources to maintain several
kinds of full skins for CMFDefault. The browser views should *replace*
the old skins and z3c.form is quite useful for writing all the necessary
That would mean that CMFDefault-the-example-application will depend on
z3c.form. If we are going to split off the forms we need to split off
all browser views and the profiles that use these views. Something like
'cmf.app' that includes all the CMFDefault stuff Plone doesn't depend on.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests