On Fri, 2007-03-02 at 17:15 +1100, Michael Lake wrote: > Malcolm Tredinnick wrote: [...] > >>Also I'm confused on the save methods. Some exemples use form.save() and > >>others > >>define a save method under the model Class. > > > > They serve slightly different purposes. A model class may have specific > > things that need to be done upon saving. > > Hence in Mike Kellers article he defines a save in the Class definition in > models.py > as he has self.added and self.changed as datetime things which need to be > acted upon. > A default form.save() would not do that I gather so he overrides it?
I fear you might still be confusing the uses of model.save() and form.save() here. Mike Keller needed a save() method in his model for the reasons you noted: he wanted to automatically populate some particular fields on every save. Regardless of whether the saving is done via a form or some other method (e.g. a cronjob or a command-line invocation). Independent of whether or not you have a custom save() method for your models (each model has a default save() method, of course -- it just saves the currently populated attributes), you will have form.save() in the case you are considering. The form.save() method for a from_for_model() result acts as a wrapper that knows how to pull the data out of the form, put it into the model and call the model's save() method -- whether it be your custom one or the default one. > > Now, again, because forms and > > web-interfaces in general are not the only way to create and update > > model instances, some of the saving logic definitely belongs to the > > model class. > > > > On the other side, when you automatically create a form from a model > > (using form_for_model(), it creates a special "save" method that is > > really a proxy for the model's save() method, but also checks that there > > are no validation errors in the form and updates the model with the > > forms inputs. > > > > So form.save() for a form generated from form_for_model() is just a > > quick way to update and save from a form to a model. Does that clear > > things up at all, or just muddy the waters even further? > > Clears thins up a bit. So if one can do with the save() from form_for_model > then one > is lucky - use it. Otherwise if you have something special like setting a > datatime > you have to use your own save(). See above for why this might not be correct (confusion between model.save() and form.save()). The other reason you might not use form.save() is because it is kind of specific to form_for_model() forms, so it won't always exist. If I can over-simplify things a little, imagine we split the universe of Django-created forms into two groups: Group A are those forms which correspond exactly to one of your model instances (not just one model, but one instance of that model). For example, a "create object" form in the admin interface where the input fields correspond precisely to the model behind it. Group B are those forms where the input data is then munged in some way and split across possibly multiple models for storage. An example here might be a form that allows multiple teams for a competition to be entered -- the data is split across multiple model instances for saving. I find in my own form creation, that I mostly create group B forms, so form_for_model() doesn't appear in my code very much. Instead, I am responsible for splitting up the data and populating the right models and then saving them. In short, form.save() is really just a convenience method for one class of forms where saving is an easy thing to work out how to do. You may not always have it available. Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
