[Grok-dev] Re: applyChanges and add forms

[Philipp von Weitershausen]

On 16 Apr 2007, at 16:38 , Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
> [snip]
>> 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  
>> something.
>
> 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  
> event.

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.