Hi Robert,

maybe it's a little late to join this discussion. i read the thread and
want to point some of my thoughts here.

imo its a bad idea to depend on static zcml configuration for factory
types. martin did a nice approach in his portlets engine with a name
traverser when calling a generic adding view.

I'm not quite sure I follow here. The portlets machinery just looks up the add view in a utility that stores its name, and then invokes it. There's a custom analog to IAdding called "+portlet" to keep the namespace separate.

i took this idea and the
adding mechanism of devilstick works this way as well and depends on the
fti too. so a call of foo/add/portal_type returns an add view for
requested type.

How's that different to foo/+/<factory-name> ?

doing it this way would even work if someone renames a
portal_type for some reason without the needs to modify or overwrite any
existing zcml, because the traverser simply tries to read the fti of

Mmm.... right. Local components work here too, of course.

to make custom add views available there could be a new attribute in the
fti which contains the name of a custom add view to look up. the
traverser could then first lookup if a custom add view was set (this has
to be configured static with zcml anyway) and looks it up by its name or
returns the default add view. as an alternative this could also be done
by aliases.

I'm not sure you need the traverser, though, if you have a standard way to generate the list of URLs for the add view, but maybe I'm missing something?

im not sure if it is desirable to alter the IAdding mechanism with
something like a simple view. at least i see no reason for implementing
'yet another adding mechanism'.

Having the add view be a view for a view (i.e. the context of the real add view is not a content object) is sometimes quite painful.

in the end a quick question. isn't the portal_factory itself obsolete if
a clean adding mechanism is working then and the only thing to maintain
further the fti stuff?

Plone's portal_factory has nothing to do with this, but yes, we want to rip the damned thing out.


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

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

Reply via email to