Robert Niederreiter wrote:
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
requested type.
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'
traverser thing?
depends on what your traverser returns :).
consider such an url and the default formlib behaviour:
foo/+/Folder
'+' is the IAdding implementation, which is actually nothing else than a
'factory', but without creating anything like the old behaviour of the
portal_factory.
now it's possible to register an IPublishTraverse implementation for
this specific IAdding implementation (could also be anything else than
IAdding if you want to get rid of it). this traverser then does the FTI
lookup, the schema interface lookup und creates and returns the addform.
in this step you can modify the context of addform as needed.
here is how its done in devilstick:
http://dev.plone.org/collective/browser/devilstick/devilstick.browser/trunk/devilstick/browser/traversal.py
line 71+
I like pretty URLs, and 'foo/+/<MyPortalType>' looks much prettier than
the URLs needed with my approach:
foo/<AddViewName>?form.portal_type=<MyPortalType>
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.
Would anyone volunteer to implement this (including unit tests) if we
decide to choose that approach?
Cheers, Yuppie
_______________________________________________
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
