[Zope-CMF] Re: Add forms and menus

[yuppie]

Robert Niederreiter wrote:
>>>>> 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.
>> Right. That's probably a reasonable default (and is, in effect, what 
>> Dexterity does as well, although it registers add views as local adapter 
>> factories that "know" their portal_type).
>>
>>> this interface lookup, and addview/form instanciation might be done then
>>> in a traverser, that's the most 'zopeish' solution imo.
>> This is quite an interesting approach, actually. After traversal, what 
>> is self.context in the add form? Is it the form, or the 'addview' 
>> traverser thing?
> 
> depends on what your traverser returns :).
> 
> consider such an url and the default formlib behaviour:
> 
> foo/+/Folder
> 
> '+' is the IAdding implementation, which is actually nothing else than a
> 'factory', but without creating anything like the old behaviour of the
> portal_factory.
> 
> now it's possible to register an IPublishTraverse implementation for
> this specific IAdding implementation (could also be anything else than
> IAdding if you want to get rid of it). this traverser then does the FTI
> lookup, the schema interface lookup und creates and returns the addform.
> 
> in this step you can modify the context of addform as needed.
> 
> here is how its done in devilstick:
> http://dev.plone.org/collective/browser/devilstick/devilstick.browser/trunk/devilstick/browser/traversal.py
> line 71+

I like pretty URLs, and 'foo/+/<MyPortalType>' looks much prettier than 
the URLs needed with my approach:

   foo/<AddViewName>?form.portal_type=<MyPortalType>

Your proposal has some advantages. On the other hand this requires to 
create CMF specific code and patterns in a place where a more generic 
solution also works.

Would anyone volunteer to implement this (including unit tests) if we 
decide to choose that approach?

Cheers, Yuppie