[Zope-CMF] Re: Add forms and menus

[Charlie Clark]

Am 13.07.2008 um 14:08 schrieb Martin Aspeli:

Thanks for restarting the discussion and thanks to Yuppie for his  
implementation. We've been using it with the changes I outlined the  
other week to good effect for the last couple of months.

> Bah, I hate these discussions. I'm sure Daniel Nouri would be happy  
> to relicense. Re-invention for the sake of a license is just too dumb.

I think we all hate such discussions but that's the way it is when  
derivative code gets given a different licence.

> I'd prefer to keep the name to avoid breaking existing packages,  
> though.
>
> Another option is to factor out a few things to a five.z3cform and  
> have plone.z3cform import from it as appropriate.

This is probably necessary anyway. I'm not sure whether it's right to  
try and go straight to z3c.form. My understanding is that there isn't  
a great deal of difference between the two libraries so hopefully an  
implementation could live with both. I don't think that everyone has  
moved onto z3c.form - certainly that wasn't my impression at  
Europython. It would be nice to have a formlib based CMF 2.2 and I  
think I now understand most of this well enough to contribut. We could  
possibly  onto z3c.form in 2.3 which might have replaced zope.formlib  
in Zope by then.

>>> In any case, I'd like to know why you went down the portal_actions  
>>> route for rendering the add links. I'm not quite sure I like the  
>>> idea of having this be persistent configuration, separate to the  
>>> FTI, as the two would need to be kept in sync, and in sync with  
>>> the view name registered in ZCML.
>> CMF makes a distinction between portal types and content types.  
>> Portal types are persistent wrappers around the non-persistent  
>> content types. You can define many different portal types based on  
>> one content type.
>
> Right.
>
>> In CMF you add *portal type* instances, so the 'add' links should  
>> be persistent as well. The non-persistent add form has to take the  
>> portal type name as argument to create the correct portal type.
>> I'm not sure what the right solution is, but I guess extending the  
>> type info classes will be the best approach.
> >
>>> Also, why not try to use the Zope 3 menu concept? There's even a  
>>> special "add menu" directive.
>> Moving away from persistent actions is not on my todo list. And as  
>> I tried to explain above, the current portal type concept depends  
>> on persistent actions.
>
> Right, I see that. But having things in two places is obviously not  
> very desirable either.
>
>>> I'd quite like to find a good approach here that can be used by  
>>> both Plone and plain CMF, if possible.
>> I hope you find one ;)
>
> 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?

> The idea is that the factory name is unique and specific to the  
> content type. Different portal types that use the same factory would  
> almost by necessity have the same add view.
>
> We could make this overrideable as well, with another FTI property.
>
> The assumption here is that the add menu is rendered with some  
> custom code, i.e. it doesn't use the actions machinery or the Zope 3  
> browser menu concept.


Yes, I think that has to be the case.

Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226