[Zope-CMF] Re: Add forms and menus

[Martin Aspeli]

Hi Yuppie,


>>> I doubt constraints based on __setitem__ and __parent__ work in Zope 2.
>> Well, they do in the sense that if you have them and we have this code, 
>> we'll get an exception. They don't work generally, tough, so this may be 
>> YAGNI. It was copied from Five's Adding implementation, so I figured it 
>> should be kept if someone's relying on it.
> 
> That's quite hypothetical. If someone figures out how to use this for 
> stuff like the allowType check, it's useful. If not, it is YAGNI.
> 
> In case of doubt, I prefer to remove code like that and to wait until 
> someone complains.

I have no problem with doing that.

>>>>         content.id = name
>>>>         container._setObject(name, content)
>>>>         content = container._getOb(name)
>>>>                 if fti is not None:
>>>>             fti._finishConstruction(content)
>>> CMF trunk uses events instead of _finishConstruction.
>> Ah, nice. Do you think it'd be feasible to backport this, i.e. copy the 
>> event handler somewhere in Plone so long as Plone's still using an older 
>> version of CMF? Or does the new event handler rely on other changes to 
>> CMF as well?
> 
> The changes in handleContentishEvent are simple. The tricky part is to 
> make sure notifyWorkflowCreated and indexObject aren't called twice if 
> the types tool is used for creating content.

How did you?

> BTW: plone.z3cform's AddForm doesn't include a create method, so I can't 
> see your complete create-and-add procedure.

The idea is that the concrete add view implements this method. I'm not 
sure it's desirable to completely generalise this, but maybe a default 
implementation would be useful.

> You might want to compare 
> your code with the ContentAddFormBase of CMFDefault trunk:
> http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/formlib/form.py?rev=86225&view=auto

Will do!

>>>> We could make this overrideable as well, with another FTI property.
>>> I guess I'd rather have a flexible explicit URL than an implicit URL 
>>> ruled by convention.
>> Agree. So does this mean we want a separate property for the add view 
>> name? Should it be a simple string or a TALES thing?
> 
> Add links are just special 'actions', they should be integrated with 
> CMF's action machinery. Based on the information in the type infos we 
> should be able to create normal IActionInfo objects. (IActionInfo 
> defines the non-persistent wrapper around actions, today we would use 
> adapters to implement this.)
> 
> If we don't want to use a convention, we need a new property. And if we 
> want to be flexible enough to add the portal type name to the query, a 
> TALES expression for the URL wouldn't be overkill.

So, a single new property that contains TALES? Called 'addview'?

I can get with that. ;-)

Martin

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