yuppie wrote:
Robert Niederreiter wrote:
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.

Writing generic code is just the first step. Pushing this down the stack and making it the default pattern for Zope is much harder.

We may not have to, though... In Zope 3, there either:

 - is no pattern, everyone does it their own way; or
 - everyone uses IAdding views; and/or
 - everyone uses Zope 3 browser menus via ZCML

This would all be feasible for CMF except that we want to support a single content type instantiated as multiple (persistent) portal types, all of which are likely to (but may not) share a single view.

I'm still on the fence as to whether I like Robert's proposal. However, if we let 'addview' be a TALES property, then I think with his proposal it'd look like:


This would basically allow a default add view to be written that could work on all types (provided there was a way to look up the schema of that type, which there may not be in plain CMF). The view @@add would be a view providing IPublishTraverse. It'd have:

 def publicTraverse(self, request, name):
     portal_type = name
     return GenericAddView(self.context, request, portal_type)

GenericAddView could then be a form that took portal_type as a parameter and rendered an add form that knew how to configure and add this type.

This would of course just be one option - if I had a more conventional custom add form, I could do:


or whatever.

Note that we're now getting into the territory that plone.dexterity (which, by the way, aims to work with plain CMF as well) covers. It has a way for the FTI to broadcast its schema (and that schema can come from a number of places, including a filesystem interface, an XML file or some TTW configuration). It then has generic add- and edit- forms that look up this schema and render the relevant forms.

If we envisage that every "plain" type in CMF will have a custom add view registered as a regular view with a unique class (probably a good thing), then I think the @@add/portal_type pattern is overkill. It's easier just to let the FTI represent the URL to the view, and for the "menu" code that lets the user pick something to add, to loop over the FTIs of addable types and render each link in turn.


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