[Grok-dev] Re: Heads up: Renamed AddForm to Form

[Martijn Faassen]

Philipp von Weitershausen wrote:
>  From the commit log message:
> 
> - Renamed grok.AddForm to grok.Form because there was no additional
>   functionality in that base class that was specific to adding. Yes, it
>   used formlib's AddForm, but none of the features that has to make
>   adding objects easy for you were used (adding objects in Zope 3 is
>   overly complicated anyway, thanks to IAdding). Everybody writing add
>   forms was writing his/her own actions anyway, which is exactly what
>   the point of a general grok.Form base class is.
> 
> - Got rid of the "form in form" weirdness. It turns out that a very,
>   very simple mix-in with a custom render() method makes it possible to
>   mix formlib's base classes with grok.View. This makes the ViewGrokker
>   simpler and exposes more of formlib directly in Grok forms.

This is a serious design change and we've done it the way it works for 
actual reasons! It would've been nice to at least discuss these reasons 
before we dive into a massive change like this.

I'm seriously surprised it is that easy - does overriding update() work? 
What about overriding render()? I strongly suspect both now don't work. 
My oversight is that we should've had tests for both cases to make the 
intent clear. The point for the containment relationship was to avoid 
the extensive name clashes between the formlib base classes and 
fundamental grok assumptions.

Regards,

Martijn