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
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
