Adrian Holovaty wrote: > 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. >
OK, maybe I'll just wait to see how it pans out, but I think I must be missing something. I can see that you can create a Field for every built in validator and you can create custom Fields instead of custom validators. However none of this seems to cover the problem of *validator lists*. With Manipulators you could have different combinations of validators for any one of your fields, built in or custom. Are you suggesting that we would create a Field for every *combination* of validators that we need to apply to what would otherwise be built in standard Fields. Still seems like too much work here. It seems to be an issue of *creating* all the possible Fields for the validador/validator combination you want rather than just *combining* existing validators to apply to existing Fields. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
