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')
   ...

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