I'm not quite sure I follow here. The portlets machinery just looks up
the add view in a utility that stores its name, and then invokes it.
There's a custom analog to IAdding called "+portlet" to keep the
imo its a bad idea to depend on static zcml configuration for factory
types. martin did a nice approach in his portlets engine with a name
traverser when calling a generic adding view.
you post i.e. /++contextportlets++plone.rightcolumn/+/portlets.Login as
action for adding a portlet and let your ITraversable implementations
perform what to do in plone.app.portlets.browser.traversal.py.
thats imo a nice approach
Ah, I get you. Actually, the ++contextportlets++plone.rightcolumn bit is
a namespace traversal adapter that addresses a particular portlet
manager (which is basically an ordered container); + is an IAdding view
(actually, an IPortletAdding view) registered for the portlet manager
container. portlets.Login is the name of the add view for a particular
So, this approach is identical to (and borrowed from) the "old" Zope
3/ZMI approach that you have an add view that is a statically registered
view for IAdding. The adding view is *not* generic. Each portlet
registers its own add view. We have a formlib-based base class though.
Now, I think this is fine for portlets, since it's relatively easy to
register this add view (there's a single ZCML directive to register all
portlet-related information), and portlets are not like portal types
(there's no persistent FTI that can be cloned).
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
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'
Having the add view be a view for a view (i.e. the context of the real
add view is not a content object) is sometimes quite painful.
until someone got the clue :). yes you're right here, constructs like
``aq_inner(self.context.context)`` and similar simply look ugly. but on
the other hand, if you kick this construct, you have to provide another
mechanism which is responsible to finally add what has to be added. if
this is more elegant then...?
The final 'add' operation can be done by a base class for the view.
That's how Yuppie's formlib thing works, and how z3c.form prefers to work.
self.context.context can be majorly painful, though. For example, look
Here, we need to acquire something, but since the context may be the
IAdding view, we have to do this everywhere:
context = getattr(context, 'context', context)
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