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.

> 
> Would anyone volunteer to implement this (including unit tests) if we 
> decide to choose that approach?
> 
> Cheers, Yuppie

robert

> 
> 
> _______________________________________________
> 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

_______________________________________________
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

Reply via email to