[Zope-CMF] Re: Add forms and menus

[yuppie]

Hi Martin!


Martin Aspeli wrote:
>>>         # check preconditions
>>>         checkObject(container, name, content)
>>
>> 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.

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

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

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


Cheers,

	Yuppie