Conception du projet / mise en page du FS pour les grands projets de django

Quelle est la meilleure façon de mettre en page un grand projet django? Les didacticiels fournissent des instructions simples pour configurer des applications, des modèles et des vues, mais il existe moins d’informations sur la répartition des applications et des projets, sur le partage autorisé / nécessaire entre les applications d’un projet classique (qui dépend évidemment le projet) et comment / où les modèles généraux doivent être conservés.

Quelqu’un a-t-il des exemples, des suggestions et des explications sur les raisons pour lesquelles une certaine mise en page de projet est meilleure qu’une autre? Je m’intéresse particulièrement à l’incorporation d’un grand nombre de tests unitaires (2-5x la taille de la base de code réelle) et à l’externalisation / modèles de chaînes.

Les principales directives sont similaires à tout autre projet de code important. Les applications doivent répondre à une responsabilité unique et clairement définie. Le nom “application” est un abus de langage; Les applications Django doivent être considérées comme des composants réutilisables pouvant être connectés pour créer une application réelle. Les tests pour chaque application doivent être contenus dans cette application. Les applications doivent être dissociées autant que possible, mais il y aura clairement des dépendances, l’objective étant de garder le graphe de dépendance aussi simple et sain que possible.

Je préfère conserver tous les modèles pour un projet sous un seul répertoire de modèles à l’échelle du projet, avec un sous-répertoire pour chaque application (utiliser un sous-répertoire de modèle pour chaque application est une convention très forte dans Django, car elle évite les collisions entre applications) . La raison d’un répertoire de modèles à l’échelle du projet est que les modèles, les arborescences d’inheritance de modèles et les noms de blocs peuvent être spécifiques à un projet, il est donc difficile de fournir des modèles d’application “par défaut” pouvant être connectés à un projet. Il y a eu quelques tentatives pour définir des conventions de nommage standard pour les modèles de base à l’échelle du site et les blocs qu’ils définissent, mais je n’ai pas encore vu de norme émerger (la façon dont ils font les choses chez Pinax est probablement la plus proche). la norme).

En ce qui concerne “l’externalisation de chaînes”, si vous voulez dire i18n et l10n, Django a un support solide pour cela et des emplacements standard où il place les fichiers .po – vérifiez les documents .

J’ai trouvé la mise en page de Zachary très utile Le blog de Zachary Voase »Conventions du projet Django, revisité.

Cette page traite bien de certaines de mes questions: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Plus précisément:

Pour définir des balises ou des filtres de modèles personnalisés, vous devez créer un sous-répertoire dans le répertoire de l’application, appelé templatetags, qui doit contenir un fichier nommé __init__.py afin qu’il puisse être importé en tant que module Python.

Pour définir des tests unitaires qui seront automatiquement remarqués par le framework de test de Django, placez-les dans un module appelé tests (qui peut être un fichier nommé tests.py ou un répertoire appelé tests). Le framework de test trouvera également des doctests dans ce module, mais le lieu préféré pour ceux-ci est, bien sûr, les docssortingngs des classes ou des fonctions qu’ils doivent tester.

Pour fournir un SQL personnalisé qui sera exécuté immédiatement après l’installation de votre application, créez un sous-répertoire appelé sql dans le répertoire de l’application. les noms de fichiers doivent être identiques aux noms des modèles sur lesquels ils vont fonctionner; Par exemple, si vous avez une application nommée blog contenant un modèle nommé Entrée, le fichier sql / entry.sql du répertoire de l’application peut être utilisé pour modifier ou insérer des données dans la table des entrées dès sa création.

La note à propos de tests.py et de tests (le répertoire) est également valable pour les modèles, ce qui aide à résoudre le problème de la possibilité de passer par de nombreux tests (ou modèles) pour un fichier.

J’aimerais quand même voir quelques exemples / suggestions pour les applications / projets et les grands sites de django qui fonctionnent bien.

Le projet Pinax est construit autour de l’idée de petites applications réutilisables, qui sont facilement intégrées dans un projet. Ils ont utilisé le projet Cloud 27 en tant que projet de démonstration.

Le projet Django sur lequel je travaille (appelé Basie. Il est pré-0.1, donc pas de lien pour le moment.) Essaie de suivre le modèle Pinax, et jusqu’à présent, cela fonctionne assez bien.

Ma mise en page actuelle provient de mon souhait d’avoir une version test de mes sites. Cela signifie avoir deux projets pour chaque site, car ils ont besoin de configurations différentes, et me force à déplacer toutes les applications des projets.

J’ai créé deux dossiers: $ APP_ROOT / devel et $ APP_ROOT / prod. Ceux-ci contiennent toutes les applications. Utilisation du contrôle de source (dans mon cas, git) J’ai les applications en cours lors de la révision HEAD, tandis que les applications en production sont verrouillées sur la balise PROD. Les modèles ont également leur propre dossier avec la même mise en page que les applications.

Maintenant, je peux faire tout mon développement dans le dossier devel-apps et dans le dossier correspondant. Quand j’ai quelque chose dont je suis content, je marque cette révision et mise à jour prod.

J’aime vraiment le post de Randall Degges sur ce sujet. Il laisse de côté les informations sur la façon de coller les fichiers de parameters, mais j’aurai un article sur lequel je pourrai créer un lien, mais pour l’instant, tout le monde peut consulter mon repo où j’inclus une direction dans le fichier readme.