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
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
