use newforms in generic create_update view

I believe the switchover for generic views going to newforms will be sometime after the 0.96 release.

Just in case it's useful for newforms branch I'll mark this ready for checkin for Adrian to have a look at.

i checked that request.POST.copy() issue, by the way. it's not required by the forms procedure any more, but as data from request.FILE is added to the data dictionary, the copy() is still required.

Isn't this dependent on form_for_instance() being able to handle things like FileField fields?

Please move back to "ready for checkin" if I've missed something, but I think it's still missing some dependencies.

updated to trunk. fixed several issues with last patch and added form and formfield_callback overrides.

I have attached a patch that fixes several issues with the last one. Uses newforms correctly. This patch applies cleanly against trunk at r6635. I added form and formfield_callback overrides to allow for customization of the form. I removed the follow kwarg as it is not needed any longer with newforms. I am currently working on some tests and revised docs.

patch with docs and tests

I have completed writing the tests and revised the docs. For some reason Trac doesn't seem to know how to display my diff.

This change does introduce a backward incompatibility in the templates that is similar to those who move to newforms anyways. Let me know if I missed anything or need to revise anything in the patch.

revised docs and allowed fields to be customized

created save_callback for custom saving of form data

I want to point out that I have verified the patch against latest trunk r6798. However, this patch is pending the ModelForm? feature found in #6042.

updated to r6963 and using ModelForm? now. Backwards Incompatible.

I have attached a new patch that is now working with ModelForm. To do this I made this change as backwards incompatible. I think that should not be the case and use a helper function to dynamically create the ModelForm? from the model at run-time. This is found in the newforms-admin branch (modelform_for_model) so it might be good to port it to trunk? What do people think about this?

updated to r7140 and is now backward compatible by accepting a Model instance.

Why has this been moved to newforms_admin? Generic views aren't used in admin are they? If not, then it's a purely trunk thing and we should avoid doing it on the branch.

I may have got the wrong impression that newforms-admin was meant for all newforms conversions. Is that not true or is this an exception to that?

Newforms admin is for converting admin to use newforms. Like it says in the branch name.

This patch will be committed to trunk eventually, don't worry. But I, personally, haven't done it yet because of the massive backwards-incompatibility it introduces, making timing important. It should definitely be independent of newforms admin, though, so that people don't have unrelated upheavals going on at once.

Replying to mtredinnick:

Newforms admin is for converting admin to use newforms. Like it says in the branch name.

The question of the scope of the newforms-admin branch also came up when someone starting looking at converting auth to newforms. Russell's reply here:

http://groups.google.com/group/django-developers/msg/f5e0a3c5a227c123

may be where people are getting the idea that all remaining newforms conversions should be done first in the context of the newforms-admin branch. Not trying to say one way or the other where things should be done, just trying to point out where the confusion may be coming from.

Pedantic note, should this ticket's description be updated to reflect the more, er, generic goal of having all generic views use newforms, not just create_update? Certainly it's now implied by VersionOneFeatures that this is "the" ticket for such things.

The create_update views are the only ones that use forms. It would make sense that they would be the only ones :)

That's a really good point, I've been thinking too much about generic views as a single package and that didn't really occur to me. I clearly need to avoid browsing Trac tickets after overly-long work days...:)

some updates to Brian's latest patch