[Zope-CMF] Re: Add forms and menus

[Robert Niederreiter]

Am Mittwoch, den 16.07.2008, 11:33 +0200 schrieb Robert Niederreiter:
> Hi,
> 
> > So, let me try to summarise what I think we're saying here:
> > 
> >   - My type has a form like:
> > 
> > class MyAddForm(CMFBaseAddForm):
> >      fields = form.Fields(IMyType)
> >      portal_type = 'My type'
> > 
> >   - The base form knows to look at self.factory_name to look up the 
> > factory when it does the create() call.
> > 
> >   - The base add form implements ICMFAddForm
> > 
> >   - I register the form as a normal <browser:page />, with the 
> > convention that the name is the same as the factory name
> > 
> >   - The FTI has an 'addview' property, which by convention is set to 
> > string:${folder/absolute_url}/@@add/${portal_type}
> > 
> >   - The @@add view looks like
> > 
> > class AddView(BrowserView):
> >      implements(IPublishTraverse)
> > 
> >      def publishTraverse(self, request, name):
> >          portal_types = getToolByName(self.context, 'portal_types')
> >          fti = getattr(portal_types, name)
> >          factory = fti.factory
> >          addview = getMultiAdapter((self.context, request), ICMFAddForm,
> >                                        name=factory)
> >          addview.portal_type = name
> >          return addview
> > 
> > A few things to note about this:
> > 
> >   - The traverser doesn't call the view, it just returns it (the 
> > publisher will call it when it needs to)
> > 
> >   - We don't look up a default, unnamed add form view. This doesn't make 
> > any sense unless we really can generalise all forms; frameworks like 
> > Dexterity may have a way to do this and thus may be able to have their 
> > own versions of @@add, but I don't think this something we should do at 
> > the CMF level.
> +/-
> i would provide a default add form anyway. consider how archetypes
> works. you never write an addform (especially because there are
> none :)). for most of the usecases default sequencial add forms fit
> quite fine. so for most usecases even the registration for the add form
> is lost code lines.
> 
> to provide this, the CMFBaseAddForm simply has to provide one more
> property.
> 
> class CMFBaseAddForm(BrowserView):
>     
>     @property
>     def fields(self):
>         portal_types = getToolByName(self.context, 'portal_types')
>         fti = getattr(portal_types, self.portal_type)
>         return form.Fields(fti.schema)
> 
> the publishTraverse function of AddView then would do something like:
> 
>    ...
>    factory = fti.factory
>    try:
>        addview = getMultiAdapter((self.context, request),
>                                  ICMFAddForm,             
>                                  name=factory)
>    except ComponentLookupError, e:
>        addview = getMultiAdapter((self.context, request),
>                                  ICMFAddForm,             
>                                  name=u'cmfdefaultadd')
>    ...
even here could be one more place for generalizing.

    addiface = getattr(fti, 'addinginterface', ICMFAddForm)

and then lookup addview with addiface.

> 
> >   - This doesn't require any more registrations than the simple add form 
> > browser view.
> see above. this registration would be then the first possible
> customization step if desired.
> 
> > 
> >   - If I don't want to use this idiom, I could change that TALES 
> > expression to something like string:${folder/absolute_url}/@@add-my-stuff
> > 
> > I quite like this approach now. ;-)
> great :)
> 
> > 
> > Martin
> 
> Robert
> > 
> > _______________________________________________
> > Zope-CMF maillist  -  Zope-CMF at 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 at lists.zope.org
> http://mail.zope.org/mailman/listinfo/zope-cmf
> 
> See http://collector.zope.org/CMF for bug reports and feature requests