Hi developers, Having just ported to 1.2.1, I'd like to make a comment about a change that was made to the code from 1.1. I understand that you wanted to add a more generic form of model validation into the code base. But I'd just like to let folks know that changing the code such that the ModelForm is saved to an instance during post_clean has caused me, a senior developer that has been working on a django app for 18 months at a large corporation, a lot of problems.
Let me give a couple of examples: I have a fairly sophisticated web app that is using django, and a number of features in it depend on the save at exactly the point where my code calls save(). For example, I compare the initial state of an instance prior to the save to the state of the instance after the save, and print a report based on that. I also do some special stuff so that my forms save out only the fields that are changed in the form. My app has some similarities to the admin app (but more custom). Imagine that you have the admin app working in a multi user environment. What if two different users have the same admin page up, and one saves one field in an object, and the other saves another. The admin app will just save the full form for whichever user's save happens last. But my app (which is similar to the admin app in many ways) does some special stuff by modifying exclude dynamically, prior to the save, so that so that the save saves out only the fields that have been modified in the form. Yes, I know from tickets I have posted that modifying exclude dynamically is "not allowed". But saving only the fields that have changed in the form was important to my app, so I went that direction anyway, and it has worked extremely well, providing my users with an intuitive UI where multiple people can modify the same object at once, as longer as they are modifying different fields. It's not clear to me what a better way to do this would have been (on 1.1) But now on 1.2 I have no entry point that will allow me to do that, due to the fact that the save is embedded in _post_clean. I have attempted to make _post_clean() a pass, but of course that doesn't work because the validate_unique() code is now tied in to having the instance saved. Yes, I know that I did make use of the internal API in ways that it was not intended. I understood the risk, and now I will pay the price. During this time I have become intimately familiar with much of the django code base, and I am comfortable modifying it and overridding methods as needed. Hey, you gotta do what you gotta do. But it is certainly disappointing to find that 1.2 is going to require me to override so much. There are of course a variety of tacts I can take - it is by no means a show stopper. At the moment, my tact is to override _post_clean(), making it a pass, and create a clean() method for my base level form (which derives from form.Model form, and which all my other forms derive from) that calls all the old code from 1.1 (ie, validate_unique() and all that it calls). Basically I will try to use the old 1.1 ModelForm validation code, in hopes that I can continue to update to new releases. But it is painful and a shame to be copying all this 1.1 code into my app. I would suggest considering making this new model validation code path optional. IE, give users a way to stay with the old form validation. Or better yet, keep the idea of model validation, but make it more transparent by not actually saving the ModelForm to the instance. It's hard for me to believe that no other developers have encountered this same problem (the problem of having a ModelForm saved at a point in the code where you have no control). But my app may very likely present more dynamic and sophisticated functionality, used in a heavily multiuser environment, than many apps that are developed, so perhaps I am the only one that will have an issue with this. In any case, I hope this nail doesn't come across poorly. I respect the Django developers immensly, but I just want to go on record by lettting you know that you have at least one user that has been caused a lot of pain by this change. I also hope that you will accept me posting this on this "developers" board. I think it is important that you get feedback from someone who is using django heavily, in behalf of a large corporation. I find that when I post tickets, if there is any hint of me doing something out of the ordinary, that my ticket is always closed with the comment that "I shouldn't be doing that". I understand that of course you cannot accommodate everyone, and that you are working as volunteers and I totally respect that. But there is little ability for someone like me - basically one of your power users - to give feedback in any sort of useful forum. So I hope you can spend a few moments thinking about what it feels like to be in my shoes. As django moves forward, I think it might be useful to find a way to partner with corporate developers such that you get feedback like this at an earlier point. While I try to keep an eye out for where things are going with django, this change and it's impact on me just was not at all clear. Anyway, thanks for listening. I do very much appreciate all you have done to make Django a great product. Margie Roginski -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
