[Grok-dev] Re: applyChanges and add forms
Philipp von Weitershausen
philipp at weitershausen.de
Mon Apr 16 12:54:46 EDT 2007
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
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
>> 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.
More information about the Grok-dev