[Zope-CMF] Re: Add forms and menus

[yuppie]

Hi Martin!


Martin Aspeli wrote:
> I see that Yuppie has been experimenting with add forms. From what I can 
> tell, he's using a custom formlib base class and registering views as 
> e.g. addFile.html. It also look as if he's registering that view as an 
> action in portal_actions, in the 'folder' category.

That's correct. But I have to mention that not all parts of these 
changes have reached the same stage of maturation. Using 'folder' 
category Actions is a temporary hack to generate menu items for the new 
add forms. I'm glad you want to help to find a better solution.

> Plone currently supports add forms for the IAdding (+) view in a 
> somewhat ugly way (it looks to see if there's a view for IAdding with 
> the same name as the 'factory' set in the FTI of an addable type, and if 
> so, provides a link to it). IAdding can be a bit painful, so we're 
> interested in supporting an approach based on simple views.

Good.

> It's also worth noting that z3c.form (via plone.z3cform, which should be 
> plain CMF compatible, though you may want a different default template) 
> has support for such views in quite a generic way. The "CMF" version of 
> that looks like this:
> 
> http://dev.plone.org/plone/browser/plone.z3cform/trunk/plone/z3cform/add.py
> 
> z3c.form is generally nicer to work with than formlib.

Maybe we should discuss this in a different thread. Here a short reply: 
My code for the AddForm would look quite different, especially for CMF 
trunk, but in general that's the way to go. Since z3c.form became the 
standard in the Zope 3 world I'd like to see Zope 2 and CMF moving in 
the same direction. Unfortunately using plone.z3cform is no option for 
CMF because it has a different license and repository. *If* Plone wants 
to donate that code to the Zope Foundation or someone writes something 
similar (maybe five.z3cform), I'd be happy to help with CMF integration.

> 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.

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.

> 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 ;)


Cheers,

	Yuppie