Podzieliłem mój duży (7 tys. Wierszy) plik views.py na oddzielne pliki i wzrost szybkości był znaczący.
user1261774
Odpowiedzi:
190
W Django wszystko jest modułem Pythona (* .py). Możesz utworzyć folder widoku z __init__.pywnętrzem i nadal będziesz mógł importować swoje widoki, ponieważ implementuje to również moduł Pythona. Ale przykład byłby lepszy.
Twój oryginał views.pymoże wyglądać tak:
def view1(arg):passdef view2(arg):pass
Z następującą strukturą folderów / plików będzie działać tak samo:
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
Szybkie wyjaśnienie byłoby: gdy piszesz from views import view1Python będzie szukać w view1
views.py, co dzieje się w pierwszym (oryginalnym) przypadku
views/__init__.py, co dzieje się w drugim przypadku. Tutaj __init__.pyjest w stanie zapewnić metodę view1, ponieważ importuje ją.
Dzięki tego rodzaju rozwiązaniu możesz nie mieć potrzeby zmiany importlub urlpatternargumentów wurls.py
Jeśli masz wiele metod w każdym nowym pliku widoku, może się okazać, że warto dokonać importu w views/__init__.pyużytku *, na przykład:
from viewsa import*from viewsb import*
Właściwie nie wiem o problemach z szybkością (ale wątpię, czy są).
Czy możesz dodać wzorzec adresu URL, który pasuje do widoku1 lub widoku2 w Twoim przykładzie? Ponieważ mam z tym problemy ...
Pascal Klein
2
Próbowałem to zrobić, ale kiedy idę importować moje modele (z app.models import MyModel lub from models import MyModel), Python narzeka, że model nie istnieje.
Chris Miller,
Czy jest w porządku, jeśli usuniemy views.py w katalogu głównym?
Roel,
6
To rozwiązanie nie działa dla mnie (ten sam błąd niż @ChrisMiller moje rozwiązanie. W __init__.py: from myapp.views.viewsa import *. Pamiętaj, że nie może mieć views.py już (lub przynajmniej nie będą odczytywane @ShiftNTab: Błąd na nie znajdowanie swoich poglądów w views.py). Mam nadzieję, że to pomoże!
ThePhi
A co z konwencją nazewnictwa: czy nazwa pliku powinna być w liczbie pojedynczej czy mnogiej? Np .: views.car.pyvsviews.cars.py
guival
21
Musiałem to zrobić wcześniej (dla jasności)
Sposób, w jaki to zrobiłem, polegał na utworzeniu viewskatalogu, a następnie utworzeniu pliku o nazwie__init__.py
Teraz, kiedy dzwonisz urls.py, po prostu musisz dodać kolejną część
Zasadniczo możesz umieścić swój kod, gdziekolwiek chcesz. Tylko upewnij się, że odpowiednio zmieniasz instrukcje importu, np. Dla widoków w urls.py.
Nie znając swojego rzeczywistego kodu, trudno jest zasugerować coś znaczącego. Może użyć jakiś przedrostek nazwy pliku, na przykład views_helper.py, views_fancy.py, views_that_are_not_so_often_used.pyalbo tak ...
Inną opcją byłoby utworzenie viewskatalogu z __init__.py, do którego importujesz wszystkie widoki podrzędne . Jeśli potrzebujesz dużej liczby plików, możesz utworzyć więcej zagnieżdżonych widoków podrzędnych w miarę wzrostu widoków ...
Tylko po to, żeby się podzielić, miałem trochę problemów z odpowiedzią Vincenta Demeestera. Wszystko jest w porządku poza plikiem init .py, muszę napisać w ten sposób:
__init__.py :
from.viewsa import*from.viewsb import*
W ten sposób nadal nie muszę zmieniać importmetody w urls.py. Jestem na Pythonie 3.6.1 i Django 1.11.4 .
Prawie wszystkie widoki w moich aplikacjach dzielę na folder widoków ( oczywiście z init .py). Nie importuję jednak wszystkich podglądów podrzędnych w pliku init .py, jak sugerowały niektóre odpowiedzi. Wydaje się, że działa dobrze.
Ponieważ Django po prostu oczekuje, że widok będzie obiektem wywoływalnym, możesz umieścić go w dowolnym miejscu w swojej PYTHONPATH. Możesz więc na przykład po prostu utworzyć nowy pakiet myapp.views i umieścić tam widoki w wielu modułach. Będziesz oczywiście musiał zaktualizować swój adres urls.py i inne moduły, które odwołują się do wywołań tych widoków.
Ach, dobrze wiedzieć, dziękuję :-) Zawsze myślałem, że z modelkami i ich sposobem życia w pakiecie aplikacji jest trochę więcej magii. Usunąłem wiersz o modelach z mojej odpowiedzi.
Horst Gutmann
Cieszę się, że mogłem pomóc, później zdałem sobie sprawę, że ten link faktycznie wyjaśnia, jak to się robi z modelami znacznie lepiej: blog.amber.org/2009/01/19/...
Jonathan Berger
1
Bawiłem się umieszczaniem tego w moim 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))
Wciąż jestem nowy w Pythonie, więc wciąż zastanawiam się, jaki ma to wpływ na szybkość / bezpieczeństwo / łatwość użycia.
Odpowiedź Vincenta Demeestera jest znakomita! ale dla mnie odpowiedź uzależnionego działała jak urok. Miałem trudności z migracją bazy danych. Błąd wskazuje wiersz, do którego jest importowany pierwszy model, i mówi, że nie można rozpoznać modułu mojej aplikacji. Dużo szukałem, ale nie mogłem znaleźć rozwiązania, ale później zaimportowałem model w ten sposób:
Odpowiedzi:
W Django wszystko jest modułem Pythona (* .py). Możesz utworzyć folder widoku z
__init__.py
wnętrzem i nadal będziesz mógł importować swoje widoki, ponieważ implementuje to również moduł Pythona. Ale przykład byłby lepszy.Twój oryginał
views.py
może wyglądać tak:Z następującą strukturą folderów / plików będzie działać tak samo:
viewsa.py
:viewsb.py
:__init__.py
:Szybkie wyjaśnienie byłoby: gdy piszesz
from views import view1
Python będzie szukać w view1views.py
, co dzieje się w pierwszym (oryginalnym) przypadkuviews/__init__.py
, co dzieje się w drugim przypadku. Tutaj__init__.py
jest w stanie zapewnić metodę view1, ponieważ importuje ją.Dzięki tego rodzaju rozwiązaniu możesz nie mieć potrzeby zmiany
import
luburlpattern
argumentów wurls.py
Jeśli masz wiele metod w każdym nowym pliku widoku, może się okazać, że warto dokonać importu w
views/__init__.py
użytku*
, na przykład:Właściwie nie wiem o problemach z szybkością (ale wątpię, czy są).
W przypadku modeli może to być trochę trudne.
źródło
__init__.py
:from myapp.views.viewsa import *
. Pamiętaj, że nie może mieć views.py już (lub przynajmniej nie będą odczytywane @ShiftNTab: Błąd na nie znajdowanie swoich poglądów w views.py). Mam nadzieję, że to pomoże!views.car.py
vsviews.cars.py
Musiałem to zrobić wcześniej (dla jasności)
Sposób, w jaki to zrobiłem, polegał na utworzeniu
views
katalogu, a następnie utworzeniu pliku o nazwie__init__.py
Teraz, kiedy dzwonisz
urls.py
, po prostu musisz dodać kolejną częśćNa przykład wcześniej mogłeś dzwonić: -
Możesz teraz wywołać coś w stylu
To oczywiście przy założeniu, że posiadałeś
views/year.py
funkcjeindex
iuser
;)źródło
Zasadniczo możesz umieścić swój kod, gdziekolwiek chcesz. Tylko upewnij się, że odpowiednio zmieniasz instrukcje importu, np. Dla widoków w
urls.py
.Nie znając swojego rzeczywistego kodu, trudno jest zasugerować coś znaczącego. Może użyć jakiś przedrostek nazwy pliku, na przykład
views_helper.py
,views_fancy.py
,views_that_are_not_so_often_used.py
albo tak ...Inną opcją byłoby utworzenie
views
katalogu z__init__.py
, do którego importujesz wszystkie widoki podrzędne . Jeśli potrzebujesz dużej liczby plików, możesz utworzyć więcej zagnieżdżonych widoków podrzędnych w miarę wzrostu widoków ...źródło
Tylko po to, żeby się podzielić, miałem trochę problemów z odpowiedzią Vincenta Demeestera. Wszystko jest w porządku poza plikiem init .py, muszę napisać w ten sposób:
__init__.py :
W ten sposób nadal nie muszę zmieniać
import
metody w urls.py. Jestem na Pythonie 3.6.1 i Django 1.11.4 .źródło
Prosta odpowiedź: tak.
Najlepiej jest utworzyć katalog o nazwie views, a następnie w swoim urls.py zrobić:
źródło
Prawie wszystkie widoki w moich aplikacjach dzielę na folder widoków ( oczywiście z init .py). Nie importuję jednak wszystkich podglądów podrzędnych w pliku init .py, jak sugerowały niektóre odpowiedzi. Wydaje się, że działa dobrze.
źródło
Ponieważ Django po prostu oczekuje, że widok będzie obiektem wywoływalnym, możesz umieścić go w dowolnym miejscu w swojej PYTHONPATH. Możesz więc na przykład po prostu utworzyć nowy pakiet myapp.views i umieścić tam widoki w wielu modułach. Będziesz oczywiście musiał zaktualizować swój adres urls.py i inne moduły, które odwołują się do wywołań tych widoków.
źródło
Bawiłem się umieszczaniem tego w moim init .py:
Wciąż jestem nowy w Pythonie, więc wciąż zastanawiam się, jaki ma to wpływ na szybkość / bezpieczeństwo / łatwość użycia.
źródło
Załóżmy, że masz plik o nazwie:
password_generator.py
to w środkuviews.py
dodaj:from password_generator import *
Następnie możesz wywołać funkcję tego modułu z
views.py
.źródło
Odpowiedź Vincenta Demeestera jest znakomita! ale dla mnie odpowiedź uzależnionego działała jak urok. Miałem trudności z migracją bazy danych. Błąd wskazuje wiersz, do którego jest importowany pierwszy model, i mówi, że nie można rozpoznać modułu mojej aplikacji. Dużo szukałem, ale nie mogłem znaleźć rozwiązania, ale później zaimportowałem model w ten sposób:
Zadziałało!!
źródło