On 5 sep, 19:44, Rajesh Dhawan <[EMAIL PROTECTED]> wrote: > On Sep 5, 1:11 pm, TheShark <[EMAIL PROTECTED]> wrote: > > > > > I am playing with a Django project which will deal with networking > > information. I would like to enforce some additional constraints above > > and beyond what the default Form fields provides. > > > For example, if I have a model to represent a 'subnet' it would have > > both a network address (which I can save as an IPAddressField) and a > > netmask which can be an IntegerField. I want to enforce that the host > > portion of the address field is all zeros. This is pretty easy to > > calculate given the address and netmask. But where should I put such > > calcuations? > > > Class Subnet(models.Model): > > address = models.IPAddressField() > > netmask = models.IntegerField() > > > In reading the documentation I can find several places where it might > > fit: > > 1) define a new custom Field subclass which incorporates both the > > address and netmask as a single value. This would work, but I think I > > might end up with a lot of extra new Field types and doesn't really > > seem to be the right place.
Not as much a problem of "being the right place" as a problem of keeping two semantically distinct fields distincts IMHO. > > 2) override the 'save()' method on my Model subclass, and do the check > > there. This seems pretty easy, but I'm not sure what to do if I fail > > the validation. Raise ValidationError? Either way, this is the option > > I'm leaning towards now. > > If you raise an exception here, there's no standard way of showing a > message to the user. Possibly not in the admin app [1], true. But in a custom view, this should not be a problem. but OTHO, handling this kind of constraints is definitively a responsability of the model. [1] FWIW, there was a small validation framework for a time in the svn version, which (I do wonder why) was removed in 1.0, that would have solved this problem... (snip) > > 4) Use the clean_address() method of a custom ModelForm. This is > > pretty easy, and feels like it's sort of the right place because then > > I can easily give the user a nice error message. On the other hand, > > it's not really preventing the creation of invalid Subnet instances > > via other methods (say via the Admin interface). > > This is a good way to go. wrt/ the admin app, possibly. Not wrt/ correct attribution of responsabilities. > In order to benefit from the clean_address() validation, you will just > need to ensure that all your application code uses this custom > ModelForm to create and update your model instances. Indeed. <op> I'm afraid that if you want to use the admin app and still have a robust (and correct) model, you'll have to apply solutions #2 *and* #4. In order to restrict repetition to a minimum, you should factor this validation rule in a function (possibly defined in the your model's module) and call it from both the model's class save method and the custom form. </op> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
