[Zope-CMF] Re: Add forms and menus

[Martin Aspeli]

Daniel Nouri wrote:
> Daniel Nouri writes:
> 
>> Robert Niederreiter writes:
> 
>>> yuppie writes:
> 
>>>> 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')
> 
> My suggestion is rubbish.  First, it should be 'form', not
> 'formfactory'.  Then, I realize it's not the same pattern since your
> factory is supposed to do some work before it passes on control (I
> believe?) whereas mine is the add form class itself.
> 
> Both patterns require the same amount of registrations.  As many for
> IFormFactory as for IAddForm.  What's worse is that the implementations
> will have a hard time to work reusably without the portal type name,
> which they're registered with.
> 
> What about the traverser does this:
> 
>     try:
>         view = getMultiAdapter((context, request),
>                                IAddForm, name=factory_name)
>     except ComponentLookupError, e:
>         view = getMultiAdapter((context, request), IAddForm)
> 
>     view.factory_name = factory_name
>     return view()
> 
> In this case, the adapter/form would actually have a chance to work for
> more than one portal type.
> 
> How does this sound?

It still feels a bit fishy to me.

I don't really see why you need a traverser *unless* you're trying to 
have a single add form implementation that covers multiple types. You 
may of course have that, and maybe it's helpful to let people write 
that, but I think most people would prefer to write "plain" add views 
that use the standard z3c.form patterns.

For something like Dexterity, where we explicitly want to support 
"generic" content with a schema that varies according to runtime 
configuration, this is more of an issue. But even there, the intention 
is that whilst the framework has a few hooks like this so that it works 
with content that's more malleable, it doesn't force you to use 
unconventional patterns if you do something yourself on the filesystem.

In the case above, you end up having to register your form as a 
particular adapter rather than a browser view. That's fairly unnatural, 
and also doesn't necessarily deal with things like security settings. It 
makes the add view quite different to write than the edit view, too.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book