Mon views.py
est devenu trop grand et il est difficile de trouver la bonne vue.
Comment puis-je le diviser en plusieurs fichiers puis l'importer? Cela implique-t-il une perte de vitesse?
Puis-je faire la même chose avec models.py
?
Mon views.py
est devenu trop grand et il est difficile de trouver la bonne vue.
Comment puis-je le diviser en plusieurs fichiers puis l'importer? Cela implique-t-il une perte de vitesse?
Puis-je faire la même chose avec models.py
?
Réponses:
Dans Django, tout est un module Python (* .py). Vous pouvez créer un dossier de vues avec un __init__.py
intérieur et vous pourrez toujours importer vos vues, car cela implémente également un module Python. Mais un exemple serait mieux.
Votre original views.py
pourrait ressembler à ceci:
def view1(arg):
pass
def view2(arg):
pass
Avec la structure de dossier / fichier suivante, cela fonctionnera de la même manière:
views/
__init__.py
viewsa.py
viewsb.py
viewsa.py
:
def view1(arg):
pass
viewsb.py
:
def view2(arg):
pass
__init__.py
:
from viewsa import view1
from viewsb import view2
L' explication rapide serait: lorsque vous écrivez, from views import view1
Python recherchera view1 dans
views.py
, ce qui se passe dans le premier cas (d'origine)
views/__init__.py
, ce qui se passe dans le second cas. Ici, __init__.py
est capable de fournir la méthode view1 car il l'importe.
Avec ce genre de solution, vous pourriez avoir pas besoin de changer import
ou urlpattern
s argumentsurls.py
Si vous avez de nombreuses méthodes dans chaque nouveau fichier de vue, vous trouverez peut-être utile d'effectuer les importations en cours d' views/__init__.py
utilisation *
, comme ceci:
from viewsa import *
from viewsb import *
En fait, je ne connais pas les problèmes de vitesse (mais je doute qu'il y en ait).
Pour les modèles, cela peut être un peu difficile.
__init__.py
: from myapp.views.viewsa import *
. Notez que vous ne pouvez pas avoir un views.py plus (ou du moins il ne sera pas lu @ShiftNTab: erreur pour ne pas trouver votre point de vue dans views.py). J'espère que cela vous aidera!
views.car.py
vsviews.cars.py
J'ai dû faire ça avant (pour plus de clarté)
La façon dont j'ai fait cela a été de créer un views
répertoire, puis, en cela, de créer un fichier appelé__init__.py
Maintenant, lorsque vous appelez votre urls.py
, il vous suffit d'ajouter une autre partie
Par exemple, auparavant, vous avez peut-être appelé: -
url(r'^calendar/(?P<year>\d\d\d\d)/$', 'myproject.calendar.views.year')
url(r'^calendar/(?P<year>\d\d\d\d)/(?P<user>[a-z]+)/$', 'myproject.calendar.views.year_by_user')
Vous pouvez maintenant appeler quelque chose du genre
url(r'^calendar/(?P<year>\d\d\d\d)/$', 'myproject.calendar.views.year.index')
url(r'^calendar/(?P<year>\d\d\d\d)/(?P<user>[a-z]+)/$', 'myproject.calendar.views.year.user')
Ceci, bien sûr, en supposant que vous aviez views/year.py
contenant les fonctions index
et user
;)
En gros, vous pouvez mettre votre code, où vous le souhaitez. Assurez-vous simplement de modifier les instructions d'importation en conséquence, par exemple pour les vues dans le urls.py
.
Ne pas connaître votre code réel, c'est difficile de suggérer quelque chose de significatif. Peut-être vous pouvez utiliser une sorte de préfixe de nom de fichier, par exemple views_helper.py
, views_fancy.py
, views_that_are_not_so_often_used.py
ou si ...
Une autre option serait de créer un views
répertoire avec un __init__.py
, où vous importez toutes les sous- vues . Si vous avez besoin d'un grand nombre de fichiers, vous pouvez créer davantage de sous-vues imbriquées au fur et à mesure que vos vues grandissent ...
Juste pour partager, j'ai eu quelques problèmes avec la réponse de Vincent Demeester. Tout va bien sauf dans le fichier init .py, je dois écrire de cette façon:
__init__.py :
from .viewsa import *
from .viewsb import *
De cette façon, je n'ai toujours pas besoin de changer ma import
méthode dans urls.py. Je suis sur Python 3.6.1 et Django 1.11.4 .
Réponse simple: oui.
Le mieux est de créer un répertoire appelé views, puis dans votre urls.py faire:
import views
...
url(r'^classroom$', views.school.klass, name="classroom"),
J'ai divisé presque toutes les vues de mes applications dans un dossier de vues (avec un init .py bien sûr). Cependant, je n’importe pas toutes les sous-vues dans le fichier init .py, comme certaines réponses l’ont suggéré. Cela semble fonctionner très bien.
Puisque Django s'attend simplement à ce qu'une vue soit un objet appelable, vous pouvez la placer où vous voulez dans votre PYTHONPATH. Ainsi, vous pouvez par exemple simplement créer un nouveau package myapp.views et y placer des vues dans plusieurs modules. Vous devrez naturellement mettre à jour vos urls.py et les autres modules qui référencent ces callables de vue.
J'ai joué avec mettre ceci dans mon init .py:
import os
currPath = os.path.realpath(os.path.dirname(__file__))
dirFiles = []
for root, dirs, files in os.walk(currPath):
for name in files:
if name.endswith('.py') and not name.startswith('_'):
dirFiles.append(name.strip('.py'))
for f in dirFiles:
exec("from %s import %s" % (f,f))
Je suis encore nouveau dans Python, donc je suis toujours à la recherche de son effet sur la vitesse / la sécurité / la facilité d'utilisation.
La réponse de Vincent Demeester est superbe! mais pour moi, la réponse du toxicomane a fonctionné comme un charme. J'ai rencontré des difficultés lors de la migration de la base de données. L'erreur indique la ligne où le premier modèle est importé et indique que je ne peux pas reconnaître mon module d'application. J'ai beaucoup cherché mais je n'ai pas trouvé de solution, mais plus tard j'ai importé le modèle comme ceci:
from ..models import ModelName
Ça a marché!!