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
``portal_type``.
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.
Martin
_______________________________________________
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
