Opening a ticket would be the way to go if there isn't one open already.
Joseph
So I've thought a little bit about putting access to "what's changed"
in the BaseModelForm class. It would be a very nice feature to have,
it could be lazy, and the modelform already has access to the original
object *and* the form data. No idea what the API would look like
though. If you want to propose something, I'll certainly participate
in the discussion.
I suppose it *could* go in BaseForm, but the pattern there seems to be
"use initial, or use data, but not both".
Joseph
> Didn't see one so I opened one, #6117. From a brief look it seems to me the
> way to determine what has changed would be to compare the cleaned_data
> values for fields to the corresponding initial values? If you think that's
> the right general approach, I could take a look at working up a patch. (Or
> if there's a different approach that should be taken, you could point me in
> that direction.)
So I've thought a little bit about putting access to "what's changed"
in the BaseModelForm class. It would be a very nice feature to have,
it could be lazy, and the modelform already has access to the original
object *and* the form data. No idea what the API would look like
though. If you want to propose something, I'll certainly participate
in the discussion.
I suppose it *could* go in BaseForm, but the pattern there seems to be
"use initial, or use data, but not both".
+1 from me, BaseForm sounds useful.
On the other hand all the magic is tied to Form (including the
metaclass) and most forms already extend the Form itself (and
form_for_* can be told to do so by passing Form as their base class
parameter).
--
Patryk Zawadzki
PLD Linux Distribution