> * As a side effect, generic create/update views will not be able to > use edit_inline stuff; that will only be an admin feature. I am 100% > fine with that, as I have never seen a need for using edit_inline out > of the admin -- it is an admin-specific phenomenon. We could indeed > expose the logic of determining edit_inline stuff so people can use it > for themselves, but it wouldn't be a core part of models, as is > currently the case with automatic manipulators. > > That's all I had time to write up on a plane trip this evening. > Comments, thoughts, ideas? > > Adrian
I agree in general with putting validation in the model. However... I don't really understand how some things are going to work here. * Are you literally going to destroy the manipulator code, and shove that functionality into the admin ( in a way that I can't see being anything but incomprehensible...) ? There seems to be a disturbing trend of 'oh, thats complicated, lets shove it/keep it in as an unreadable special case in the admin code, with inevitable tendrils throughout the ORM that can't easily be used by anything else.' Examples : change logging, permissions, seemingly now form handling in general (!) This is exactly the opposite of the aim I had when I did the new-admin branch. * Is every view that people write going to have to have a bunch of code that pulls individual fields out of the POST data ? Or what? I really have no idea what you mean by 'automatic manipulators go away'.... do you just mean they are accessed in a different way (eg AddManipulator(MyModel) ) , not as a property of the model class? Or are you actually getting rid of that functionality? * Partial object updates also rely on the follow code in the manipulator. Maybe you never needed that personally though, so why not destroy it - same rationale as edit-inline. * Validation of multiple fields as mentioned before. Also cross-object validation becomes literally impossible, whereas with a composite manipulator model it was a possibility. * The hack fields like auto_now and auto_now_add will need a rethink. I really don't have much of an idea what you can do to make these sensible. Some callback on .save() maybe. * file upload fields are an even bigger problem without the manipulator. ie does every view need a special cased thing for them? If you are going to make this large a change in the code for every view, its probably worth looking at the whole sequence of calls in the average view - html2python, manip.flatten_data(), error checking ( which is currently only done at the wrong stage, before the data is converted, on the raw post data). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
