Chris Long wrote: > Maybe, but if you do it in the template then it won't even show the > option to the user and you'll avoid the trouble of getting the error > from the save method to be displayed to the user.
Oh, I see where you're going with it. Just hide the interface from the user. That's a great idea, I still need a way though to enforce it so that carefully crafted POST requests don't allow unauthorized users from breaking things. > If all you're using is an Integer, then I'd suggest just subclass the > integer field and leave most of it the same as it is and only override > the part where it returns the form field. Should avoid a lot of > trouble. That was my first pass. I subclassed models.IntegerField and overroad get_manipulator_field_objs, and return my custom Form. However, when running syncdb I still got a KeyError. I think that there is a dict somewhere that maps models to their sql implementation and that my model doesn't exist in that dict, hence a KeyError. But that's really just a guess. I'd love to hear from an authority about where the sql structure of a model is defined. Thanks again Chris, you're thoughts have really helped -- mthorley --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
