[Zope-CMF] Re: Add forms and menus

Martin Aspeli optilude at gmx.net
Tue Jul 15 17:21:13 EDT 2008


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
>> implementations.
>>
>> like:
>>
>> formfactory = getAdapter(context,
>>                          IFormFactory,
>>                          name='factoryNameFromFti')
>> 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:

  string:${folder/absolute_url}/@@add/mytype

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:

  string:${folder/absolute_url}/@@my-add-view

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.

Martin


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



More information about the Zope-CMF mailing list