[Zope-CMF] Re: Add forms and menus

Martin Aspeli optilude at gmx.net
Mon Jul 14 16:31:34 EDT 2008


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



More information about the Zope-CMF mailing list