[Grok-dev] Re: applyChanges and add forms

[Martijn Faassen]

Philipp von Weitershausen wrote:
> 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.

+1

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

Ah, okay. We should allow applyChanges to continue working but raise a 
deprecation warning when we use it then. It's in use in too many places 
to suddenly break again, I think. :)

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

Do we want to do that in AddForm at all? AddForm after all creates the 
object and already (presumably) triggers an IObjectAdded event. Doing an 
IObjectModified event straight afterward would be doing things twice. 
Sounds like applyData in add forms want to do the real minimum to just 
set attributes based on the schema.

Regards,

Martijn