Robert Niederreiter writes: > Am Dienstag, den 15.07.2008, 12:43 +0200 schrieb yuppie: >> 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. > > 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.
If I understand this correctly, it should be more like: formfactory = getMultiAdapter((context request), IAddForm, name='factoryNameFromFti') We could even leave 'factoryNameFromFti' empty by default. I like this approach! Daniel _______________________________________________ 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