Daniel Nouri wrote:
Daniel Nouri writes:
Robert Niederreiter 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,
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),
except ComponentLookupError, e:
view = getMultiAdapter((context, request), IAddForm)
view.factory_name = factory_name
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