Je comprends former la documentation http://docs.djangoproject.com/ FR / DEV / REF / MODÈLES / DOMAIRES / Pour que vous puissiez ajouter ERROR_MESSAGES à un champ modèle et fournir votre propre dict de messages d'erreur. Cependant, quelles sont-elles des clés du dict que vous êtes censé passer? S'il est plus facile de le faire sur le Modelform utilisé qui fonctionnerait également. Je préférerais ne pas avoir à créer explicitement créer chaque champ et leur type à nouveau. C'est ce que j'essayais d'éviter: update 2: Code de test utilisé dans mon projet Mon modèle: mon formulaire: ma vue:
3 Réponses :
Vous avez raison, ces documents ne sont pas très utiles. C'est un ajout récent après tout!
Je suppose que l'utilisation normale des erreurs_messages est destinée à modeloforms, donc je regarderais ici une liste de clés d'erreur acceptables par champ: http://docs.djangoproject.com/fr/dev/ref/Forms/fields/#Error-Messages p> La voie la plus fiable va maintenant être En regardant la source à django / db / modèles / champs / __ init __. py code> où vous verrez chacun des par défaut_error_messages code> qui peut être spécifié et les appels réels sur Self.Error_Messages ['Invalid'] Code> P> class SubscriptionGroup(models.Model):
name = models.CharField(max_length=255, error_messages={'blank': 'INVALID!!11', 'null': 'NULL11!'})
# shell
>>> s = SubscriptionGroup()
>>> s.full_clean()
ValidationError: {'name': [u'INVALID!!11']}
J'ai pris un coup d'oeil dans les fichiers source que vous avez mentionnés et je suis arrivé à la même conclusion. Comme vous le voyez dans mon exemple, je passe une clé "requise" dans ERROR_MESSAGES, mais cela ne fonctionne pas. Maby J'ai fait quelque chose de mal quelque part, je vais devoir continuer à tester. Merci!
Hmm, ça marche pour moi! Soin de poster votre code? Je mettant à jour la mienne pour montrer ma session Shell maintenant.
C'est tellement bizarre, j'ai ajouté mon code utilisé dans l'application. Pour l'instant, j'utilise la méthode que j'ai essayé d'éviter. Cependant, votre exemple fonctionne clairement et est la bonne façon de le faire.
Ehh, malgré ce que j'ai écrit dans une phrase de ma réponse, cela ressemble à ce que cela devrait être un comportement attendu pour les modelons de ne pas hériter des validateurs de nettoyage des modèles. code.djangoproject.com/ticket/13693 (ma méthode utilise la validation du modèle, pas la validation du formulaire )
J'ai essayé. Cela ne fonctionnera pas si vous l'avez défini dans les modèles.
Vous devez définir error_messages dans vos formulaires comme celui-ci
(peu en retard à celui-ci, mais j'ai été à travers les mêmes problèmes moi-même, en utilisant cela comme une note_to_self autant que n'importe quoi.)
Vous pouvez spécifier Si vous avez un champ de modèle appelé "citation", avec une longueur maximale de 140 et un modelForm associé à ce modèle, les messages d'erreur fonctionneront ainsi:
SO - Assez simple en résumé - Les messages d'erreur correspondent à l'objet validé - ce qui peut être le modèle ou le modelform. error_messages sur les modèles et les models. Les touches que vous devriez / pouvez utiliser sont définies ici pour les champs de formulaire. Le problème semble être (pour moi) l'interfonction entre les formulaires et le modèle associé et quel message d'erreur apparaît et quand. La clé de cela est de comprendre que les formes et les modèles sont en fait très lâchés et qu'il n'y a pas vraiment de magie.
is_valid () ou erreurs ), le message d'erreur qui revient sera du modèle.