On Fri 13 Jul 2007, Todd O'Bryan wrote: > On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote: > > On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > > Is there a good reason not to do something like the following in > > > django.db.models.Model? > > > > > > def form(self): > > > return form_for_instance(self) > > > > > > @classmethod > > > def form(cls): > > > return form_for_model(cls) > > > > Yes -- the good reasons against it are that it ties form logic to the > > model and quashes the field namespace (disallowing you from having a > > field named "form"). > > How separate do you intend the models and forms to be? As it stands > right now, forms can have validators, but if you actually want to > validate programmatically what you're doing to the database, you have to > repeat any validation code you put in the form somewhere in your model. > > For example, I'm storing ISBNs. They have a check digit. I can write a > nice ISBN validator that checks the check digit, but I have to attach it > to the form *and* figure out somewhere to call it in the model to be > sure illegal ISBNs don't get stored to the database. If I ever get > around to trying to check forms client-side, I'll need to supply that > information in a third way. (Ignore briefly the fact that client-side > validation would have to be in JavaScript.)
Off topic I know, but FWIW Postgresql has a ISBN specific datatype which might be of use in your situation. Cheers -- Peter Nixon http://peternixon.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
