[Zope-CMF] Re: Add forms and menus

[Robert Niederreiter]

hi martin,

Am Montag, den 14.07.2008, 21:31 +0100 schrieb Martin Aspeli:
> 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.

you post i.e. /++contextportlets++plone.rightcolumn/+/portlets.Login as
action for adding a portlet and let your ITraversable implementations
perform what to do in plone.app.portlets.browser.traversal.py.

thats imo a nice approach

> 
> > 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> ?

not that much. i only wanted to say that there might be no need to
register a seperate addview/form for every portal type. having the type
name it should be possible to get the schema interface of the requested
type, so it's possible to provide a generic addview/form.

this interface lookup, and addview/form instanciation might be done then
in a traverser, that's the most 'zopeish' solution imo.

> 
> > 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.

until someone got the clue :). yes you're right here, constructs like
``aq_inner(self.context.context)`` and similar simply look ugly. but on
the other hand, if you kick this construct, you have to provide another
mechanism which is responsible to finally add what has to be added. if
this is more elegant then...?

> 
> > 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.

great

> 
> Martin

robert