Joseph Kocherhans wrote: > I just uploaded a patch [1] for class based generic views that use > ModelForm internally. Personally, I think this makes the generic views > a lot more flexible, and gives us a great argument against > adding-yet-another-config-argument-to-generic-views (even though I > haven't heard that particular demand come up for awhile.) Just > subclass the generic view, and do what you need.
I like the flexibility that the class-based approach brings. I think a similar idea could be used to clean up the duplication happening in the date based generic views. Anyone know if that has been attempted? > Anyhow, here's what I have in mind for the backwards compatibility story: > > This patch leaves the old generic views as-is, using manipulators. > This partially fixes the problem, we get ModelForm based generic views > living side by side with the old manipulator based ones. People can > svn up without breaking anything, and convert their code at their > convenience. At some point I think we'll want to either get rid of the > old functions, or convert them to use the new classes (should be > trivial). Personally, I'd rather do the former, but I'm probably in > the minority there. I'm with you on keeping them side-by-side and then removing the manipulator-based views when we take out oldforms. Gary --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
