[Grok-dev] Re: applyChanges and add forms
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 16 11:39:17 EDT 2007
On 16 Apr 2007, at 16:38 , Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
>> Right. Perhaps applyChanges should be
>> * amended to support the add form use cases
>> * and renamed to applyData or something similar
>> One could argue that we should have two methods, applyChanges
>> (only applies changes) and applyData (always applies all data, no
>> checking), but I'm inclined to say that this is a choice the
>> novice Grok developer won't necessarily care about. If we make
>> applyChanges do the right thing on even when the attributes aren't
>> there, I think everybody would be happy. But perhaps I'm missing
> I think we're on the right track. I'd be in favor of renaming
> applyChanges to applyData, and making applyData on AddForm call
> some other code path which simply stuffs the attributes on the
> object no matter what. On EditForm it would be calling applyChanges.
Good. I can make that change if nobody objects.
> I guess applyChanges still works due to subclassing, which is
> potentially confusing. Perhaps we should do some more trickery to
> make sure that the user cannot call this directly...
There's no applyChanges on zope.formlib forms so there's nothing to
inherit. zope.formlib has an applyChanges function somewhere that our
applyChanges method calls. The new applyData method would call this
function in case of EditForms.
> We need to verify what happens with the applyChanges return value
> right now. We also need to study what triggers the ObjectModified
Yes. Calling the applyChanges method currently sends the
ObjectModified event and it returns a boolean value which indicates
whether the object was changed at all.
More information about the Grok-dev