[Zope-CMF] Re: Add forms and menus

[Martin Aspeli]

Hi Yuppie,

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

Ah, good.

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

I'm curious how it would look different. Now is the time to get the 
correct base class behavior in plone.z3cform, before we release a new 
version of it.

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

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

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

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book