Les signaux d'enregistrement / de suppression sont généralement favorables dans les situations où vous devez apporter des modifications qui ne sont pas complètement spécifiques au modèle en question, ou qui pourraient être appliquées à des modèles qui ont quelque chose en commun, ou pourraient être configurés pour une utilisation dans plusieurs modèles.
Une tâche courante dans les save
méthodes remplacées est la génération automatisée de slugs à partir d'un champ de texte dans un modèle. C'est un exemple de quelque chose qui, si vous deviez l'implémenter pour un certain nombre de modèles, bénéficierait de l'utilisation d'un pre_save
signal, où le gestionnaire de signal pourrait prendre le nom du champ slug et le nom du champ à partir duquel générer le slug. Une fois que vous avez quelque chose comme ça en place, toute fonctionnalité améliorée que vous mettez en place s'appliquera également à tous les modèles - par exemple en recherchant le slug que vous êtes sur le point d'ajouter pour le type de modèle en question, pour assurer l'unicité.
Les applications réutilisables bénéficient souvent de l'utilisation de signaux - si la fonctionnalité qu'elles fournissent peut être appliquée à n'importe quel modèle, elles ne voudront généralement pas (sauf si c'est inévitable) que les utilisateurs doivent modifier directement leurs modèles pour en bénéficier.
Avec django-mptt , par exemple, j'ai utilisé le pre_save
signal pour gérer un ensemble de champs qui décrivent une arborescence pour le modèle qui est sur le point d'être créé ou mis à jour et le pre_delete
signal pour supprimer les détails de l'arborescence de l'objet à supprimer et son ensemble sous-arborescence d'objets devant lui et ils sont supprimés. En raison de l'utilisation de signaux, les utilisateurs ne pas ajouter ou modifier save
ou delete
savoir méthodes ont sur leurs modèles pour cette gestion fait pour eux, ils ont juste de laisser django-MPTT quels modèles ils le veulent gérer.