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

[Philipp von Weitershausen]

On 16 Mar 2007, at 08:54 , Martijn Faassen wrote:
> Martijn Faassen wrote:
>> 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.

You're totally right. Wrong eagerness on my part. I was a bit  
frustrated with the "form in form" stuff and when I wanted to extend  
it to support the simple Form base class. I was seriously irritated  
by all the back and the forth of "the old way".

I do apologize, the checkin should've happened in a branch. I offer  
to revert my changes.

>> I'm seriously surprised it is that easy - does overriding update()  
>> work? What about overriding render()?

No.

In the context of a form, I don't think that makes sense. If you want  
to process form data or render something from a form, you write an  
action. The action can return stuff which will be used as the form's  
output.

I think automated forms have different semantics than views. In  
views, update() and render() are your hooks, while the hooks in forms  
are actions. It's sort of this way in Zope 3, too. You wouldn't  
override a formlib's __call__.

>> 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.
>
> Reviewing it a bit more, I see we did have tests for 'render()',  
> which you removed. I'm not sure why we decided to completely forbid  
> the use of 'render' in this context anymore. Did you remove the  
> tests as you couldn't make them work? :)

In a way. Today I wanted to supply additional tests for this to  
demonstrate what happens when you override update() and render(). I  
should've done that earlier.

> The reasons we went through the whole rigamole with form-in-form in  
> the first place was that formlib base classes define a whole bunch  
> of methods and attributes that enter the view's namespace.

I guess it's a matter of preference, but that I actually like. It  
gives me more control, easier access to stuff and grok forms don't  
have to defer to the internal form all the time whenever they want to  
use something.

> The original design by Christian and Wolfgang was this way, but it  
> was a very primitive prototype and didn't work very well.

I'm not sure what I'm supposed to do with this information. It seems  
that my 'prototype' works well, whatever 'working well' means.

> JW and I thought for a long time on how to make this work by a  
> subclassing relationship, but concluded it was not a good approach  
> because of the namespace pollution problem. It makes it impossible  
> for Grok to inspect the view class for things like 'render()' and  
> 'update()', as they are already defined on base classes. Instead I  
> then went to the design you just wiped out.
>
> I'm not sure whether update() was a problem at the time we did the  
> design actually, as I think it was still called before(), but it  
> certainly is now.
>
> The idea of grok base classes is that what's in there is strictly  
> controlled and limited. We don't want to surprise users with a lot  
> of stuff when they subclass something from Grok. Pulling in formlib  
> base classes tends to break this assumption.

I suppose we disagree with this assumption (see above). It certainly  
would be possible to allow people to provide a custom render() and  
update() method on forms.

> Besides that philosophical issue, the biggest problem is that you  
> can't use 'update()' in form subclasses at all with the current  
> design. With the original design it does work (I just tried).

Yup, though again, I'm questioning that use case.

Philipp