[Grok-dev] Re: applyChanges and add forms

[Philipp von Weitershausen]

On 16 Apr 2007, at 18:46 , Martijn Faassen wrote:
>>> 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. :)

I'm not too fond of deprecation anymore, especially if we haven't had  
a release yet. We don't even have a deprecation policy. I hate  
deprecation cruft.

I'd be fine if we'd say "let's deprecate it for 2 weeks", though I  
don't even see the point. The change is purely mechanical, we haven't  
proposed to change the signature.

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

Yup.