On Thu, 2007-07-12 at 18:21 -0400, Todd O'Bryan wrote: > form_for_instance and form_for_model are great, but if you have to tweak > the form in any way (say you want to use a non-default widget for one of > the data fields) and want to use it more than once, you're reduced to > defining a new Form class or at least a new callback function to control > the field types. And where do you put that? For me, it's pretty clearly > an attribute of the model in the same way that a utility method would > be, because it just doesn't have any meaning without the model. So you > put it in the model.
You're projecting your particular design preferences onto everything else here. Not a horrible thing, since everybody has different preferences. However, you are also making a mountain out of a molehill in the process: you are talking about trying to save one import. The other way to look at the functionality you are doing is that they don't belong anywhere near the models, since one model is not tied to a single form. models and forms may (or may not) intersect. That intersection will often not happen in the model file, since the model is the data representation. It might happen in the view file, if it's small enough. You might decide to create a file (or module) containing a bunch of forms for a partiular presentation format. In any case, the form *processing* is going to happen in the view (or be controlled by the view). It's a presentation-related piece of functionality. To which you will answer, "but I think it should go in the model." Which can already be done. That's the beauty of namespaces, aliases and imports. Forcing it into the model space is a compulsory merging of two not necessarily related pieces of functionality. The argument that we already have the slightly dirty formfield() method in db.models.fields is not really a counter, either. It's not a perfect construct (I would rather have tied model fields to a corresponding form field in the forms namespace, since it's presentation, not semantic), but it shouldn't be used as the top end of a slippery slope to make things worse. I'm -1 one on this for pretty much the same reasons as Adrian. It's just not that big a deal even for people who want to work the way you do. Regards, Malcolm -- Despite the cost of living, have you noticed how popular it remains? http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
