Où doivent résider les fonctions utilitaires dans Django ?

Question

Où doivent vivre les fonctions utilitaires dans Django? Des fonctions telles que le cryptage/décryptage personnalisé d'un nombre, l'envoi de tweets, l'envoi d'e-mails, la vérification de la propriété d'objet, la validation d'entrée personnalisée, etc. Des choses répétitives et personnalisées que j'utilise à plusieurs endroits dans mon application. Je ne respecte définitivement pas le principe DRY en ce moment.

J'ai vu des démos où les fonctions étaient définies dans models.py, bien que cela ne me semblait pas conceptuellement correct. Doivent-elles aller dans une application "utilities" qui est importée dans mon projet? Si c'est le cas, où vont-elles dans l'application utilities? Dans le fichier models.py là-bas?

Merci de venir en aide à ce n00b.

MISE À JOUR: Soyez encore plus spécifique. Disons que j'ai besoin d'une fonction "light_encrypt(number)" qui prend le paramètre "number", le multiplie par 7, ajoute 10 et renvoie le résultat, et une autre fonction "light_decrypt(encr_number)" qui prend le paramètre "encr_number", soustrait 10, divise par 7 et renvoie les résultats. Où mettrais-je cela dans mon arborescence Django? Ce n'est pas du middleware, n'est-ce pas? Comme le suggère Felix, dois-je créer un package Python et l'importer dans la vue où j'ai besoin de ces fonctions?

Answer 1

Différente question mais même réponse :

Mon agencement habituel pour un site django est :

projects/
templates/
common/
local/

Où :

• projects contient votre projet principal et tout autre
• common contient des éléments que vous pouvez partager entre les sites, ou qui ne sont pas spécifiques au projet, comme si vous avez besoin de télécharger django-profile et django-registration plutôt que de les avoir directement dans python/site-packages
• templates contient juste cela
• local contient des éléments spécifiques à la machine actuelle, pour que vous puissiez avoir des données séparées correctement, comme l'emplacement de la base de données et le mot de passe - je lie alors les versions spécifiques à la machine (disons "machine1-localconfig.py") à local/localconfig.py et puis je peux "import localconfig" dans settings.py
• Je mets généralement les middleware spécifiques au projet à l'intérieur d'un projet, et les middleware qui ne sont pas spécifiques au projet dans common/middleware/
• Assurez-vous d'ajouter le répertoire des templates à l'endroit approprié dans les paramètres (ou plus probablement, dans localconfig.py et ensuite l'importer dans les paramètres), et assurez-vous d'ajouter les répertoires projects, common et local à votre PYTHONPATH.

Answer 2

OK, après avoir lu les commentaires et réponses ici, j'ai décidé de créer un répertoire appelé "common/util/" à l'intérieur de mon répertoire de projet. À l'intérieur, j'ai un fichier "__init__.py" où j'ai mes petites fonctions d'aide.

Je suppose que si le fichier devient trop volumineux, je vais alors diviser les fonctions en fichiers .py individuels dans common. Donc maintenant, la structure de mon projet ressemble à ceci. Veuillez corriger si je fais de mauvais choix, je suis assez tôt dans le développement pour pouvoir le corriger maintenant alors que c'est encore facile à faire!

monprojet/         (projet Django) 
  common/  
    util/
      __init__.py  (fonctions d'aide)  
  middleware/      (middleware personnalisé)  
  templates/       (modèles de projet)  
  myapp/
    fixtures/      (données initiales à charger)
    migrations/    (migrations de south)
    urls/
    views/
    admin.py
    forms.py
    models.py
    test.py

 public/           (contenu statique non servi par Django)
   media/
     css/
     img/
     js/
     lib/

Answer 3

Il dépend si les fonctions sont spécifiques au projet ou à l'application.

Les autres réponses abordent déjà où le placer pour les fonctions spécifiques au projet. Plus précisément, dans un dossier appelé common à la racine du projet.

S'il s'agit de fonctions spécifiques à l'application, je les placerais simplement à l'intérieur de l'application dans un fichier nommé utils.py, comme

myproject/         (projet Django) 
  common/  
    util/
      __init.py__    (fonctions spécifiques au projet)  
  myapp/
    migrations/    (migrations de myapp)
    utils.py            (fonctions spécifiques à myapp)
    views.py
    admin.py
    forms.py
    models.py
    test.py

Answer 4

Voici une autre façon de le faire:

Si les fonctions utilitaires peuvent être un module indépendant et que vous utilisez un environnement virtualenv pour votre application django alors vous pouvez regrouper la fonctionnalité sous forme de package et l'installer dans votre virtualenv.

Cela facilite l'importation où vous en avez besoin dans votre application django.