[Zope-CMF] Re: Add forms and menus

[Daniel Nouri]

Robert Niederreiter writes:

> Am Dienstag, den 15.07.2008, 12:43 +0200 schrieb 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.
>
> it does not if you call a formfactory inside the traverser, so it's
> hoohable for CMF, Plone or whatever even with different formlib
> implementations.
>
> like:
>
> formfactory = getAdapter(context,
>                          IFormFactory,
>                          name='factoryNameFromFti')
> return factory()
>
> which handles all the magic in there. just a thought.

If I understand this correctly, it should be more like:

  formfactory = getMultiAdapter((context request),
                                IAddForm,
                                name='factoryNameFromFti')

We could even leave 'factoryNameFromFti' empty by default.

I like this approach!


Daniel