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:


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


formfactory = getAdapter(context,
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),

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:

        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.


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

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to