On 12/10/06, Benjamin Slavin <[EMAIL PROTECTED]> wrote: > 1) I think that ComboField is a great idea, but I don't think it > handles all use cases gracefully. There's a rich collection of > validators that have been created that would not be easily accessible > if we have to use ComboField or create our own custom fields > (isValidUSState and isValidIPAddress4 come to mind). > > Having to create new subclasses of Field for existing validators > doesn't seem to fit with the DRY principles. > > I think that validator_list is an elegant (and consistent) solution.
Ah, but we *will* have USStateField and IPAddress4 field -- I just haven't written those Field classes yet. :) If the argument is "It violates DRY to have to create a Field subclass just to handle an existing validator," I'm not sure that argument flies, because we will eventually have a Field for every validator. Ideally, validators wouldn't even *exist* anymore, as Fields can take their place completely. > 2) I'd also like to see min_value and max_value for the IntegerField. > We have parameters for length on CharFields, it seems that value > constraints for IntegerFields would be a good thing as well. This is a good idea -- I've implemented it in [4218]. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
