Dividi meu grande arquivo views.py (7k linhas) para separar arquivos e o aumento na velocidade foi significativo.
user1261774
Respostas:
190
No Django, tudo é um módulo Python (* .py). Você pode criar uma pasta de visualização com um __init__.pyinterior e ainda poderá importar suas visualizações, porque isso também implementa um módulo Python. Mas um exemplo seria melhor.
Seu original views.pypode ficar assim:
def view1(arg):passdef 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 view1Python 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 importou urlpatterns 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__.pyuso *, desta forma:
from viewsa import*from viewsb import*
Na verdade, eu não sei sobre problemas de velocidade (mas duvido que exista).
Você poderia adicionar um padrão de URL que corresponda a view1 ou view2 no seu exemplo? Porque eu estou tendo problemas com isso ....
Pascal Klein
2
Tentei fazer isso, mas quando vou importar meus modelos (do app.models import MyModel ou dos modelos import MyModel), o Python reclama que o modelo não existe.
Chris Miller
Tudo bem se excluirmos o arquivo views.py no diretório raiz?
Roel
6
Esta solução não funciona para mim (mesmo erro que para @ ChrisMiller. Minha solução: em __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!
ThePhi
E a convenção de nomenclatura: o nome do arquivo deve ser singular ou plural? Por exemplo: views.car.pyvsviews.cars.py
guival 28/11
21
Eu tive que fazer isso antes (por uma questão de clareza)
A maneira como fiz isso foi criar um viewsdiretó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: -
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.pyou assim ...
Outra opção seria criar um viewsdiretó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 importmétodo em urls.py. Estou no Python 3.6.1 e Django 1.11.4 .
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.
Ah, bom saber, obrigado :-) Eu sempre pensei que havia um pouco mais de mágica envolvida com os modelos e como eles vivem no pacote de aplicativos. Removida a linha sobre modelos na minha resposta.
Horst Gutmann
Ainda bem que pude ajudar, eu percebi mais tarde que esta ligação realmente explica como é feito com modelos muito melhor: blog.amber.org/2009/01/19/...
Jonathan Berger
1
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')andnot 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:
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:Com a seguinte estrutura de pastas / arquivos, funcionará da mesma maneira:
viewsa.py
:viewsb.py
:__init__.py
:A explicação rápida seria: quando você escreve, o
from views import view1
Python procura por view1 emviews.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
ouurlpattern
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:Na verdade, eu não sei sobre problemas de velocidade (mas duvido que exista).
Para modelos, pode ser um pouco difícil.
fonte
__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 partePor exemplo, anteriormente, você pode ter chamado: -
Agora você pode ligar para algo como
Obviamente, isso pressupõe que você
views/year.py
continha as funçõesindex
euser
;)fonte
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 ...fonte
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 :
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 .fonte
Resposta simples: Sim.
O melhor é criar um diretório chamado views e, em seu urls.py, faça:
fonte
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.
fonte
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.
fonte
Eu tenho brincado em colocar isso no meu init .py:
Ainda sou novo no python, então ainda estou analisando o efeito que ele tem na velocidade / segurança / facilidade de uso.
fonte
Suponha que, se você tiver um arquivo chamado
password_generator.py
:, em seguida,views.py
adicione:from password_generator import *
Então você pode chamar a função desse módulo de
views.py
.fonte
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:
Funcionou!!
fonte