Meu views.py
tornou-se muito grande e é difícil encontrar a visão correta.
Como o divido em vários arquivos e depois o importo? Isso envolve alguma perda de velocidade?
Posso fazer o mesmo com models.py
?
Meu views.py
tornou-se muito grande e é difícil encontrar a visão correta.
Como o divido em vários arquivos e depois o importo? Isso envolve alguma perda de velocidade?
Posso fazer o mesmo com models.py
?
Respostas:
No Django, tudo é um módulo Python (* .py). Você pode criar uma pasta de visualização com um __init__.py
interior e ainda poderá importar suas visualizações, porque isso também implementa um módulo Python. Mas um exemplo seria melhor.
Seu original views.py
pode ficar assim:
def view1(arg):
pass
def view2(arg):
pass
Com a seguinte estrutura de pastas / arquivos, funcionará da mesma maneira:
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
A explicação rápida seria: quando você escreve, o from views import view1
Python procura por view1 em
views.py
, que é o que acontece no primeiro caso (original)
views/__init__.py
, que é o que acontece no segundo caso. Aqui, __init__.py
é capaz de fornecer o método view1 porque o importa.
Com este tipo de solução, você pode ter nenhuma necessidade de mudar import
ou urlpattern
s argumentosurls.py
Se você tiver muitos métodos em cada novo arquivo de visualização, poderá ser útil fazer as importações em views/__init__.py
uso *
, desta forma:
from viewsa import *
from viewsb import *
Na verdade, eu não sei sobre problemas de velocidade (mas duvido que exista).
Para modelos, pode ser um pouco difícil.
__init__.py
:. from myapp.views.viewsa import *
Observe que você não pode mais ter um views.py (ou pelo menos não será lido @ShiftNTab: erro para não . encontrar os seus pontos de vista em views.py) Espero que ajude!
views.car.py
vsviews.cars.py
Eu tive que fazer isso antes (por uma questão de clareza)
A maneira como fiz isso foi criar um views
diretório e, em seguida, criar um arquivo chamado__init__.py
Agora, quando você está ligando urls.py
, basta adicionar outra parte
Por exemplo, anteriormente, você pode ter chamado: -
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')
Agora você pode ligar para algo como
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')
Obviamente, isso pressupõe que você views/year.py
continha as funções index
e user
;)
Basicamente, você pode colocar seu código, onde quiser. Apenas certifique-se de alterar as instruções de importação de acordo, por exemplo, para as visualizações no urls.py
.
Não sabendo o seu código real, é difícil sugerir algo significativo. Talvez você possa usar algum tipo de prefixo do nome, por exemplo views_helper.py
, views_fancy.py
, views_that_are_not_so_often_used.py
ou assim ...
Outra opção seria criar um views
diretório com um __init__.py
, onde você importa todas as subvisões . Se você precisar de um grande número de arquivos, poderá criar mais subvisões aninhadas à medida que suas visualizações aumentarem ...
Só por compartilhar, tive alguns problemas com a resposta de Vincent Demeester. Está tudo bem, exceto no arquivo init .py, eu tenho que escrever desta maneira:
__init__.py :
from .viewsa import *
from .viewsb import *
Dessa forma, ainda não preciso alterar meu import
método em urls.py. Estou no Python 3.6.1 e Django 1.11.4 .
Resposta simples: Sim.
O melhor é criar um diretório chamado views e, em seu urls.py, faça:
import views
...
url(r'^classroom$', views.school.klass, name="classroom"),
Dividi quase todas as visualizações nos meus aplicativos em uma pasta de visualizações (com um init .py, é claro). No entanto, não importo todas as subvisões no init .py, como sugeriram algumas das respostas. Parece funcionar muito bem.
Como o Django apenas espera que a visualização seja um objeto que pode ser chamado, você pode colocá-lo onde quiser no seu PYTHONPATH. Assim, você poderia, por exemplo, criar um novo pacote myapp.views e colocar visualizações em vários módulos lá. Naturalmente, você precisará atualizar seu urls.py e outros módulos que fazem referência a essas exibições de chamadas.
Eu tenho brincado em colocar isso no meu 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))
Ainda sou novo no python, então ainda estou analisando o efeito que ele tem na velocidade / segurança / facilidade de uso.
A resposta de Vincent Demeester é excelente! mas para mim a resposta do viciado funcionou como um encanto. Enfrentei dificuldades na migração do banco de dados. O erro indica a linha em que o primeiro modelo foi importado e diz que não foi possível reconhecer meu módulo de aplicativo. Pesquisei muito, mas não consegui encontrar uma solução, mas depois importei o modelo assim:
from ..models import ModelName
Funcionou!!