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

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


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

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to