Hi, 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 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. 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 ``portal_type``. 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. 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'. 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? i did not studied z3c.form yet, so no statement to this from my side. regards robert _______________________________________________ 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