newforms-admin change history

5 views
Skip to first unread message

Karen Tracey

unread,
Dec 3, 2007, 2:17:14 PM12/3/07
to django-d...@googlegroups.com
In testing out the latest (r6864) newforms-admin branch I noticed that the change history for items I changed always said "No fields changed." even though I was changing fields.  Looking at the code I see it's because the old change history code is commented out, with a big TODO comment.  I don't know if I should open a ticket for stuff like this?  Or add it to the TODO list on the wiki page for the branch?  Or...?

Karen

Joseph Kocherhans

unread,
Dec 3, 2007, 2:29:17 PM12/3/07
to django-d...@googlegroups.com

Opening a ticket would be the way to go if there isn't one open already.

Joseph

Karen Tracey

unread,
Dec 3, 2007, 3:22:57 PM12/3/07
to django-d...@googlegroups.com

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

Karen

Joseph Kocherhans

unread,
Dec 3, 2007, 3:31:16 PM12/3/07
to django-d...@googlegroups.com

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

Karen Tracey

unread,
Dec 4, 2007, 2:49:46 PM12/4/07
to django-d...@googlegroups.com
On 12/3/07, Joseph Kocherhans <jkoch...@gmail.com> wrote:
> 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.

Ah, you'd like to push the responsibility for reporting changes down into the form itself, which could be generally useful outside of admin.  Sounds good.  I'll try to find time to look into it and see if I can't come up with a proposed API.

I suppose it *could* go in BaseForm, but the pattern there seems to be
"use initial, or use data, but not both".

Anyone want to register an opinion on how deep in the hierarchy this should go?  Seems to me it could be generally useful for BaseForm to be able to report what fields' cleaned values are different from what was specified as initial data. 

Karen


Patryk Zawadzki

unread,
Dec 4, 2007, 6:35:58 PM12/4/07
to django-d...@googlegroups.com
2007/12/4, Karen Tracey <kmtr...@gmail.com>:

> Anyone want to register an opinion on how deep in the hierarchy this should
> go? Seems to me it could be generally useful for BaseForm to be able to
> report what fields' cleaned values are different from what was specified as
> initial data.

+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

Reply all
Reply to author
Forward
0 new messages