Qu'est-ce qui vous empêche d'utiliser myproduct.myproduct? Ce dont vous avez besoin pour y parvenir consiste grosso modo à faire ceci:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
etc. Serait-il utile que je dise views.pyqu'il ne faut pas appeler views.py? À condition que vous puissiez nommer, sur le chemin python, une fonction (généralement package.package.views.function_name) qu'elle sera gérée. Aussi simple que cela. Tous ces trucs «projet» / «app» ne sont que des paquets python.
Maintenant, comment êtes-vous censé le faire? Ou plutôt, comment pourrais-je le faire? Eh bien, si vous créez un élément important de fonctionnalités réutilisables, comme dire un éditeur de balisage, qui est lorsque vous créez une « application de haut niveau » qui pourrait contenir widgets.py, fields.py, context_processors.pyetc. - toutes les choses que vous voudrez peut - être importer.
De même, si vous pouvez créer quelque chose comme un blog dans un format assez générique entre les installations, vous pouvez le terminer dans une application, avec son propre modèle, un dossier de contenu statique, etc., et configurer une instance d'un projet django pour l'utiliser. le contenu de l'application.
Il n'y a pas de règles strictes et rapides disant que vous devez le faire, mais c'est l'un des objectifs du cadre. Le fait que tout, y compris les modèles, vous permet d'inclure à partir d'une base commune signifie que votre blog doit s'intégrer parfaitement dans toute autre configuration, simplement en prenant soin de sa propre partie.
Cependant, pour répondre à votre préoccupation réelle, rien ne dit que vous ne pouvez pas travailler avec le dossier de projet de niveau supérieur. C'est ce que font les applications et vous pouvez le faire si vous le souhaitez vraiment. Cependant, je n'ai pas tendance à le faire pour plusieurs raisons:
- La configuration par défaut de Django ne le fait pas.
- Souvent, je veux créer une application principale, donc j'en crée une, généralement appelée
website. Cependant, à une date ultérieure, je souhaiterais peut-être développer des fonctionnalités originales uniquement pour ce site. En vue de le rendre amovible (que je le fasse ou non), j'ai tendance à créer un répertoire séparé. Cela signifie également que je peux supprimer cette fonctionnalité simplement en dissociant ce package de la configuration et en supprimant le dossier, plutôt que de supprimer de manière complexe les bonnes URL d'un dossier global urls.py.
- Très souvent, même quand je veux faire quelque chose d'indépendant, il a besoin d'un endroit pour vivre pendant que je le soigne / je le rend indépendant. Fondamentalement, le cas ci-dessus, mais pour les choses que j'ai l'intention de faire génériques.
- Mon dossier de niveau supérieur contient souvent quelques autres éléments, y compris, mais sans s'y limiter, les scripts wsgi, les scripts sql, etc.
- Les extensions de gestion de django reposent sur des sous-répertoires. Il est donc logique de nommer les packages de manière appropriée.
En bref, la raison pour laquelle il existe une convention est la même que n'importe quelle autre convention - cela aide quand il s'agit d'autres personnes travaillant avec votre projet. Si je vois, fields.pyje m'attends immédiatement à ce qu'il contienne du code pour sous-classer le champ de django, alors que si je vois, inputtypes.pyje ne serais peut-être pas aussi clair sur ce que cela signifie sans le regarder.