Dlaczego ten projekt istnieje?

Django powstało w odpowedzi na konkretny problem: World Online, dział WWW gazety w Lawrence, jest odpowiedzialny za intensywne tworzenie aplikacji internetowych z dziennikarskimi terminami. W szybko zmieniającym sie środowisku prasowym, World Online ma niekiedy tylko kilka godzin na wykonanie skomplikowanej aplikacji internetowej, licząc od koncepcji do publicznego uruchomienia.

Jednocześnie deweloperzy World Online zawsze byli perfekcjonistami, jeżeli chodzi o najlepsze praktyki tworzenia aplikacji internetowych.

Pod koniec 2003 roku deweloperzy World Online (Adrian Holovaty i Simon Willison) zerwali z PHP i zaczęli używać Pythona do rozwijania serwisów internetowych. Podczas intensywnego tworzenia bogatych, interaktywnych serwisów, takich jak Lawrence.com, zaczęli wydobywać wspólne elementy tworzenia serwisów internetowych, które pozwoliły im coraz szybciej budować aplikacje. Stale ulepszali ten framework, dodając coraz to nowe funkcje.

Latem 2005 roku firma World Online zdecydowała się na publiczne udostępnienie powstałego oprogramowania jako Django. Ponieważ stworzenie Django nie byłoby możliwe bez całej masy projektów wolnego oprogramowania — Apache, Python, PostgreSQL oraz jeszcze kilku innych — byli zachwyceni, że mogą odwdzięczyć sie tym społeczności wolnego oprogramowania.

Co oznacza “Django” i jak się to wymawia?

Nazwa Django pochodzi od Django Reinhardt, cygańskiego gitarzysty jazzowego z lat 1930-1950. Do dnia dzisiejszego jest uważany za jednego z najlepszych gitarzystów wszechczasów.

Posłuchaj tej muzyki, a spodoba Ci się.

Django wymawiamy JANG-oh, rym z FANG-oh. D jest tutaj nieme (tak wymawiają Amerykanie).

Udostępniamy także nagranie audio przedstawiające wymowę.

Czy Django jest stabilne?

Tak. Firma World Online używa Django od więcej niż trzech lat. Serwisy budowane na Django bez większych problemów wytrzymują ruch na poziomie jednego miliona wyświetleń na godzinę, a nawet więcej. Tak, jest całkiem stabilne.

Czy Django jest skalowalne?

Tak. W porównaniu do całkowitego kosztu budowy aplikacji internetowej, sprzęt jest dość tani. Dlatego też Django jest tak zaprojektowane, aby maksymalnie wykorzystać środowisko sprzętowe w którym będzie pracować.

Django wykorzystuje architekturę “shared-nothing”, co oznacza możliwość dodawania sprzętu na dowolnym poziomie — serwery baz danych, serwery cache oraz serwery WWW.

Framework czysto rozdziela takie komponenty jak warstwa bazy danych i warstwa aplikacji. Dostarcza również prosty (lecz o ogromnych możliwościach) framework cache.

Kto za tym stoi?

Django zostało stworzone w firmie World Online, dziale WWW gazety w Lawrence, Kansas, USA.

Adrian Holovaty

Adrian jest deweloperem webowym z dziennikarskim doświadczeniem. Był głównym programistą w World Online przed 2,5 roku, czyli w czasie, w którym Django zostało stworzone i wdrożone na serwisach World Online. Teraz pracuje w washingtonpost.com budując bogate, bazodanowe serwisy informacyjne oraz kontynuuje rozwój Django. Lubi grać na gitarze (w stylu Django Reinhardta) oraz udziela się w pobocznych projektach, takich jak chicagocrime.org. Mieszka w Chicago.

Na IRC’u , Adrian jest znany jako adrian_h.

Jacob Kaplan-Moss

Jacob to zapaleniec z Kalifornii, który podobną ilość czasu spędza na pisaniu kodu i gotowaniu. Jest głównym programistą w World Online, ale aktywnie uczestniczy również w kilku innych projektach pobocznych. Uczestniczył w tworzeniu dowiązań ObjC dla Pythona i był pierwszą osobą, która wymyśliła, w jaki sposób pisać w Pythonie aplikacje Tivo. W ostatnim czasie stara się uruchomić Pythona na PSP. Mieszka w Lawrence, Kansas, USA.

Na IRC’u, Jacob jest znany jako jacobkm.

Simon Willison

Simon jest szanowanym deweloperem z Angli. Miał roczny staż w World Online, podczas którego on oraz Adrian stworzyli Django od podstaw. Jest to najbardziej entuzjastyczny Brytyjczyk jakiego kiedykolwiek byś mógł spotkać, jest pasjonatem najlepszych praktyk tworzenia serwisów internetowych oraz od lat pisze często czytany i znany blog web developerski http://simonwillison.net. Pracuje dla Yahoo w Wielkiej Brytanii, gdzie udało mu się zdobyć tytuł “Hacker Liason.” Mieszka w Londynie.

Na IRC’u, Simon jest znany jako SimonW.

Wilson Miner

Projektowe sztuczki Wilcona sprawiają, że czujemy się wszyscy jak gwiazdy rocka. Za dnia jest interaktywnym projektantem Apple. Nie pytaj go nad czym pracuje, bo będzie musiał Cię zabić. Mieszka w San Francisco.

Na IRC’u, Wilson jest znany jako wilsonian.

Jakie serwisy używają Django?

Strona Wiki Django zawiera ciągle powiększającą się listę serwisów opartych o Django. Śmiało możesz dodać tam Twój serwis oparty o Django. Dodatkowo możesz przejrzeć serwis DjangoSites., który kolekcjonuje wszystkie serwisy używające Django.

Django wydaje się być framework’iem o wzorcu MCV, ale nazywacie kontroler “widokiem”, widok “szablonem”. Dlaczego nie używacie standardowych nazw?

Podejście do nazw standardowych jest dyskusyjne.

W naszej interpretacji wzorca MVC, “widok” opisuje dane, które są prezentowane użytkownikowi. To niekoniecznie jak dane wyglądają, ale które dane są prezentowane. Widok opisuje, które dane widzisz, a nie jak je widzisz. To subtelna różnica.

W naszym przypadku “widok” jest wywołaniem funkcji Pythona przez konkretny URL, dlatego że wywołanie funkcji opisuje, które dane są prezentowane.

Ponadto, uważamy za rozsądne oddzielać zawartość od prezentacji — w tym miejscu dochodzimy do szablonów. W Django “widok” opisuje, które dane są prezentowane, ale widok jest przekierowywany do szablonu, który opisuję jak dane są prezentowane.

Gdzie w takim razie jest “kontroler”? W przypadku Django jest to prawdopodobnie sam framework: mechanizm, który wysyła żądanie do odpowiedniego widoku zgodnie z konfiguracją URL’i Django.

Jeżeli mielibiśmy stosować skróty, moglibyśmy powiedzieć, że Django jest frameworkiem “MTV” — czyli “model”, “szablon”, “widok”.

Mamy pracę do zrobienia i ostatecznie liczy się efekt — nie ważne jak rzeczy się nazywają. Django wg nas pozwala, wykonać tą pracę w najbardziej logiczny sposób.

<Framework X> ma <funkcje Y> — Dlaczego nie ma jej w Django?

Jesteśmy świadomi tego, że na święcie są inne znakomite frameworki. Nie jesteśmy przeciwni zapożyczania pomysłów, kiedy uznamy to za stosowne. Jednak Django zostało stworzone dlatego, że nie byliśmy zadowoleni ze status quo. Tak więc bądź świadom, że argument typu “ponieważ <Framework X> to ma” nie jest wystarczającym powodem na dodanie danej funkcji do Django.

Dlaczego napisaliście Django od podstaw zamiast użyć gotowych bibliotek Pythona?

Kilka lat temu, na początku powstawania Django, Adrian i Simon spędzili całkiem sporo czasu na rozpoznaniu różnych dostępnych Pythonowych frameworków WWW.

Niestety żadne z nich nie były dla nas w pełni zadowalające.

Jesteśmy wybredni. Możesz nawet nas nazwać perfekcjonistami (z terminami).

Z czasem natknęliśmy się na biblioteki open-source, wykonujące rzeczy, które już mieliśmy zaimplementowane. Zauważyliśmy, że inni ludzie rozwiązują podobne problemy w podobny sposób, jednak było już za późno na integrację: mieliśmy już napisane, przetestowane i zaimplementowane własne kawałki fremeworka w kilku ustawieniach produkcyjnych — i nasz kod uroczo spełniał wszystkie wymagania.

W wielu przypadkach obserwowaliśmy, że istniejące frameworki/narzędzia miały pewnego rodzaju fundamentalne wady, które sprawiły, że staliśmy się wybredni. Żadne narzędzie nie zgadzało się w 100% z naszą filozofią.

Tak jak wspominaliśmy: jesteśmy wybredni.

Udokumentowaliśmy naszą filozofię na stronie filozofii projektowej (en).

Czy Django jest systemem zarządzania treścią (CMS)?

Nie, Django nie jest CMS’em, ani żadnym tego typu produktem. To framework webowy; narzędzie programistyczne, które ułatwia budowanie serwisów internetowych.

Nie m sensu porównywać Django z projektami typu Drupal. Django to narzędzie, za pomocą którego możesz stworzyć właśnie systemy takie jak Drupal.

Oczywiście, automatyczny panel administracyjny Django jest fantastyczny i oszczędza czas — jest on jednak tylko jednym z modułów Django. Choć w Django wygodnie tworzy się aplikacje typu “CMS”, nie oznacza to, że nie nadaje się ono do budowania aplikacji “nie-CMS” (cokolwiek to oznacza!).

Jak mogę pobrać dokumentacje Django, aby czytać ją offline?

Dokumentacja Django jest dostępna w katalogu docs każdego pakietu Django. Pliki dokumentacji są w formacie ReST (ReStructured Text). Każdy plik odpowiada stronie www z oficjalnej dokumentacji.

Ponieważ dokumentacja jest trzymana w systemie kontroli wersji (en), możesz śledzić jej zmiany, tak jakbyś przeglądał zmiany w kodzie.

Technicznie rzecz ujmujac, dokumentacja na stronie głównej Django jest generowana z najnowszej wersji deweloperskiej plików ReST. Może się więc okazać, że treść na głównej stronie Django oferuje więcej informacji niż wersja dostarczana ze stabilnym pakietem Django.

Gdzie mogę znaleźć programistów Django szukających zleceń?

Sprawdź naszą stronę programiści do zatrudnienia (en), znajdziesz tam całą listę programistów, którzy z radością Ci pomogą.

Jak zacząć?

1. Pobierz źródła.
2. Zainstaluj Django (przeczytaj poradnik instalacyjny).
3. Wykonaj tutorial.
4. Przeczytaj dokumentację i zadawaj pytania jeśli tylko nie będziesz umiał sobie z czymś poradzić.

Jak mam naprawić błąd “install a later version of setuptools”?

Uruchom skrypt ez_setup.py w dystrybucji Django.

Jakie wymagania ma Django?

Django wymaga Pythona 2.3 lub nowszego. Żadna inna biblioteka nie jest wymagana do normalnego używania Django.

Dla środowiska rozwojowego — jeżeli po prostu chcesz poeksperymentować z Django — nie potrzebujesz mieć zainstalowanego dedykowanego serwera WWW; Django dostarcza swój własny “lekki” serwer rozwojowy. Dla środowiska produkcyjnego, zalecamy Apache 2 oraz mod_python. Pamiętaj jednak, że Django spełnia kreteria określone w specyfikacji WSGI, co oznacza że możesz go używać z różnymi platformami serwerowymi.

Jeżeli chcesz używać Django z bazą danych, będziesz potrzebował także silnika bazy danych. Polecamy PostgreSQL, ponieważ jesteśmy jego fanami, jednak MySQL, SQLite 3 i Oracle są również wspierane.

Czy coś tracę używając Pythona 2.3 zamiast najnowszego, takiego jak Python 2.5?

Nie. Django samo w sobie gwarantuje że będzie działać z każdą wersją Pythona od 2.3 i wyższych.

Oczywiście jeżeli będziesz używać nowszej wersji Pythona niż 2.3, będziesz w stanie skorzystać z nowych możliwości języka jakie oferuje nowsza wersja Pythona razem ze zwiększeniem wydajności i pozostałymi optymalizacjami jakie zostały wykonane w samym języku Python. Mimo wszystko framework Django powinien działać tak samo dobrze z Pythonem 2.3 jak i 2.4 czy 2.5.

Czy muszę używać mod_python’a?

W prawdzie zalecamy stosowanie mod_pythona na użytek produkcyjny, jednak nie musisz go używać, dzięki temu, że Django korzysta ze specyfikacji WSGI. Django może porozumiewać się z dowolnym serwerem, który wspiera standard WSGI. Inne konfiguracje nie używające mod_python’a to FastCGI, SCGI, AJP, mod_wsgi. Zobacz Jak używać Django z FastCGI, SCGI lub AJP (en) aby uzyskać więcej informacji.

Zobacz także stronę Przygotowanie serwera (en) aby poznać inne sposoby wdrożenia.

Jeżeli tylko chcesz się pobawić i przetestować Django na swoim komputerze, użyj serwera WWW, który jest dostarczony razem z Django - na pewno się sprawdzi.

Jak zainstalować mod_python na Windows?

• Dla Python’a 2.4, pobierz build win32 dla mod_pytona dla Pythona 2.4 (en).
• Dla Python’a 2.4, sprawdź ten poradnik Django na Windows (en).
• Dla Python’a 2.3, pobierz mod_python’a z http://www.modpython.org/ i przeczytaj Uruchamianie mod_python’a na Apache na Windows2000 (en).
• Zobacz także to (nie związane z Windowsem) Poradnik jak uruchomić mod_pythona (en).

Czy Django będzie działać na hostingu dzielonym (jak TextDrive lub Dreamhost)?

Zobacz stronę Django - przyjazne hostingi (en).

Czy powinienem używać oficjalnej wersji czy rozwojowej?

Developerzy Django ulepszają Django każdego dnia, są dobrzy w tym co robią i nie publikują nie działającego kodu. My używamy wersji rozwojowej (z repozytorium Subversion) bezpośrednio na naszych serwerach i uważamy, że jest stabilna. Mając to na myśli, polecamy stosowanie najnowszej wersji rozwojowej, ponieważ generalnie zawiera więcej funkcji i mniej usterek niż “oficjalne” wydanie.

Dlaczego mam błąd w imporcie DJANGO_SETTINGS_MODULE?

Upewnij się że:

• Zmienna środowiskowa DJANGO_SETTINGS_MODULE wskazuje na pełny moduł Pythona (np. “mysite.settings”).

• Sprawdź czy moduł znajduje się w sys.path (import mysite.settings powinno działać).

• Sprawdź, czy moduł nie zawiera błędów składni (oczywiste).

• Jeżeli używasz mod_pythona, ale bez request handlera z Django, musisz obejść błąd mod_python’a związany z używaniem SetEnv; zanim zaimportujesz cokolwiek z Django, musisz wykonać następującą czynność:

  os.environ.update(req.subprocess_env)
  

  (gdzie req jest obiektem request mod_pythona).

Nie mogę znieść waszego języka szablonów. Czy muszę go używać?

Sądziliśmy że nasz system szablonów jest najlepszą rzeczą pod słońcem, jednak wiemy, że wybór języka szablonów jest bliski religii. Nie ma nic w Django, co wymagałoby używania Djangowego systemu szablonów, więc śmiało możesz używać każdego innego — wybór należy do Ciebie.

Czy muszę używać waszej warstwy modelu/bazy danych?

Nie. Zupełnie tak jak z systemem szablonów, warstwa modelu/bazy danych jest oddzielona od reszty frameworka.

Jedyny wyjątek to: jeżeli używasz innej biblioteki do obsługi bazy danych, wówczas nie będziesz mógł używać automatycznie generowanego panelu administracyjnego. Panel ten związany jest z warstwą bazy danych Django.

Jak używać pól typu obrazek i plik?

Używanie pól FileField lub ImageField w modelu wymaga kilku kroków:

1. W pliku ustawień projektu (settings.py) zdefiniuj MEDIA_ROOT jako pełną ścieżkę do katalogu, gdzie będziesz chciał, aby Django gromadziło wgrywane na serwer pliki. (Z powodów wydajnościowych pliki te nie są trzymane w bazie danych.) Zdefiniuj MEDIA_URL jako bazowy publiczny URL tego katalogu. Upewnij się, że ten katalog ma prawa zapisu na serwerze WWW.
2. Dodaj pole FileField lub ImageField do Twojego modelu, upewnij się, że zdefiniowałeś opcje upload_to, aby Django wiedziało, który pod katalog z MEDIA_ROOT ma użyć podczas wgrywania plików na serwer.
3. W bazie danych zostanie zapisana ścieżka do pliku (relatywna do MEDIA_ROOT). Aby pobrać pełen URL do pliku, możesz skorzystać funkcji którą dostarcza Django get_<nazwapola>_url. Na przykład, jeżeli Twoje pole ImageField nazywa się mug_shot, możesz pobrać pełen URL do Twojego obrazka w szablonie za pomocą {{ object.get_mug_shot_url }}.

Jak mogę zobaczyć rzeczywiste zapytanie SQL podczas działania Django?

Upewnij sie że ustawienie DEBUG z Django ma wartość True. Następnie (używając shell-a wpisz:

>>> from django.db import connection
>>> connection.queries
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls',
'time': '0.002'}]

connection.queries dostępne jest tylko, jeżeli DEBUG jest równe True. To jest lista słowników w kolejności wywołania zapytania. Każdy słownik ma:

``sql`` -- Treść zapytania SQL
``time`` -- Jak długo zajęło wykonanie zapytania, w sekundach.

connection.queries zawiera wszystkie zapytania SQL — INSERT’y, UPDATE’y, SELECT’y, itd. Za każdym razem, gdy Twoja aplikacja wykonuje zapytanie do bazy, zapytanie zostanie zapamiętane.

Czy mogę użyć Django z istniejącą bazą danych?

Tak. Zobacz Integracja z istniejącą bazą danych (en).

Jeżeli wprowadzę zmiany do modelu, to jak mogę zrobić update bazy danych?

Jeżeli nie jest dla Ciebie problemem wyczyszczenie danych, to narzędzie manage.py z Twojego projektu ma opcję resetowania SQL dla konkretnej aplikacji:

manage.py reset twoja_aplikacja

To polecenie usuwa wszystkie tabele skojarzone z twoja_aplikacja i tworzy je na nowo.

Jeżeli jednak nie chcesz usunąć danych, musisz ręcznie wykonać wyrażenie ALTER TABLE na Twojej bazie danych. W taki sposób robiliśmy to zawsze, ponieważ działanie na danych to delikatna operacja dlatego też w tym przypadku chcieliśmy uniknąć automatyzacji. Trwają prace, aby dodać funkcjonalność częściowej automatyzacji aktualizacji schematu bazy danych (przp. tłum. zainteresuj się narzędziem dbmigration (en) dla Django`).

Czy modele w Django obsługują klucze główne składające się z kilku kolumn?

Nie. Obsługiwane są tylko jednokolumnowe klucze główne.

W praktyce to nie jest problem, ponieważ nic Cię nie zatrzymuje przed dodaniem innego ograniczenia (używając opcji modelu unique_together lub tworząc ograniczenie bezpośrednio w bazie danych), wymuszając unikalność na tym poziomie. Jednokolumnowe klucze główne są potrzebne, aby interface admina mógł działać; np. musisz w łatwy sposób być w stanie określić obiekt do edycji lub usunięcia.

Jak dodać specyficzne opcje dla bazy danych do wyrażenia CREATE TABLE, takie jak określenie typu tabeli jako MyISAM?

Staramy się unikać specjalnych przypadków w kodzie Django, aby spełnić wszystkie specyficzne opcje baz danych takie jak typy tabel itd. Jeżeli chciałbyś używać jakichkolwiek z tych opcji, stwórz plik inicjujący dane SQL (en), który zawiera wyrażenie ALTER TABLE modyfikujące to, co potrzebujesz. Pliki inicjujące są wykonywane na bazie danych po wyrażeniach CREATE TABLE.

Na przykład, jeżeli używasz MySQL’a i chciałbyś, aby Twoje tabele używały typu MyISAM, stwórz plik inicjujący dane i wstaw tam coś takiego:

ALTER TABLE moja_aplikacja_mojatabela ENGINE=MyISAM;

Jak opisano w dokumentacji, pliki inicjujące dane SQL (en), plik SQL może zawierać dowolny kod SQL, tak więc możesz dokonać dowolnych zmian, jakich potrzebujesz.

Dlaczego Django ma wycieki pamięci?

Django nie jest znane z wycieków pamięci. Jeżeli zauważysz, że procesy Django alokują coraz więcej pamięci bez śladu zwalniania jej, sprawdz czy Twoje ustawienie DEBUG ma wartość True. Jeżeli DEBUG ustawione jest na True, wtedy Django zapisuje każde wykonane zapytanie SQL.

(Zapytania są zapisane w django.db.connection.queries. Zobacz Jak mogę zobaczyć rzeczywiste zapytanie SQL podczas działania Django?.)

Aby naprawić problem, ustaw DEBUG na False.

Jeżeli potrzebujesz wyczyścić listę zapytań ręcznie w Twoim kodzie, po prostu wywołaj reset_queries() w taki sposób:

from django import db
db.reset_queries()

Nie mogę się zalogować. Kiedy wprowadzam nazwę użytkowanika oraz hasło, pojawia się strona logowania bez żadnych błędów.

Login cookie nie został poprawnie ustawiony, ponieważ domena cookie wysłana przez Django nie zgadza się z domeną Twojej przeglądarki. Spróbuj dwóch rzeczy:

• Ustaw SESSION_COOKIE_DOMAIN w pliku konfiguracyjnym, aby pasowało do Twojej domeny. Na przykład jeżeli w przeglądarce otwierasz adres “http://www.mojserwis.pl/admin/“, w ustawieniach Twojego projektu powinieneś ustawić SESSION_COOKIE_DOMAIN = 'www.mojserwis.pl'.
• Niektóre przeglądarki (Firefox?) nie lubią akceptować cookies z domen, które nie mają kropek w środku. Jeżeli używasz panelu administracyjnego na “localhost” lub w innej domenie która nie ma kropek w nazwie, spróbuj użyć “localhost.localdomain” lub “127.0.0.1” dla ustawienia SESSION_COOKIE_DOMAIN.

Nie mogę się zalogować. Kiedy wprowadzam nazwę użytkownika oraz hasło, pojawia strona logowania, z błędem “Proszę wprowadź poprawną nazwę użytkownika i hasło”.

Jeżeli jesteś pewien, że Twoja nazwa użytkownika i hasło są poprawne, upewnij się, że Twój użytkownik ma ustawione is_active oraz is_staff na True. Panel administracyjny pozwala na dostęp tylko użytkownikom, którzy mają te dwa pola ustawione na True.

Jak mogę zapobiec, aby cache middleware nie cache’ował panelu administracyjnego?

Ustaw CACHE_MIDDLEWARE_ANONYMOUS_ONLY na True. Zobacz dokumentacje cache’u, aby uzyskać więcej informacji.

Jak automatycznie ustawić wartość pola na użytkownika, który ostatnio edytował obiekt w adminie?

W tym przypadku, Django nie ma oficjalnego “właściwego” sposobu. Jednak jest to funkcjonalność, o którą prosi wielu ludzi, więc rozważamy jak to zaimplementować. Problem w tym, że nie chcemy łączyć warstwy modelu z warstwą admina oraz warstwą żądania (aby pobrać aktualnie zalogowanego użytkownika. Jest to dość zawiły problem.

Jedna osoba znalazła rozwiązanie które nie wymaga zmian w kodzie źródłowym Django (en), miej jednak na uwadze że jest to nieoficjalne rozwianie i nie ma gwarancji, że za jakiś czas nie przestanie działać.

Jak ograniczyć dostęp w panelu administracyjnym, aby obiekty mogły być tylko edytowane przez użytkowników którzy je stworzyli?

Zobacz odpowiedź na poprzednie pytanie.

Style CSS oraz obrazki pojawiają się w adminie używając serwera developerskiego, ale nie wyświetlają się gdy używam mod_pythona.

Zobacz serwowanie plików admina (en) w dokumencie “Jak używać Django z mod_pythonem”.

Mój “list_filter” zawiera pole ManyToManyField, ale filtr nie jest wyświetlany.

Django nie wyświetla filtra dla pola ManyToManyField jeżeli są mniej niż dwa powiązane obiekty.

Na przykład, jeżeli Twój list_filter zawiera strony, a w Twojej bazie danych jest tylko jedna taka strona, wtedy filtr “Strona” nie zostanie wyświetlony. W tym przypadku filtrowanie po stronach byłoby bezużyteczne.

Jak mogę zmienić funkcjonalność panelu administracyjnego?

Masz kilka opcji. Jeżeli chciałbyś zmodyfikować funkcjonalność w formularzu dodawania/zmiany obiektu, możesz dodać dodatkowy JavaScript przez parametr js w class Admin w modelu. Parametr ten jest listą URL’i wskazującymi na pliki JavaScript, które zostaną załadowane w formularzu admina jako znacznik <script>.

Jeżeli oczekujesz większej elastyczności niż po prostu zmieniając automatycznie wygenerowane formularze, możesz śmiało napisać własny widok dla admina. Panel administracyjny jest zasilany przez Django, więc możesz napisać własne widoki, które integrują się systemem autoryzacji, sprawdzaniem uprawnień oraz cokolwiek innego potrzebujesz.

Jeżeli chciałbyś zmienić wygląd interfejsu admina, przeczytaj kolejną opowiedź.

Dynamicznie generowany panel administracyjny jest brzydki! Jak mogę go zmienić?

Nam się podoba, ale jeżeli się nie zgadzasz, możesz zmodyfikować wygląd panelu administracyjnego przez edycje arkusza CSS oraz/lub skojarzone obrazki. Strona jest zbudowana z prostego HTML’a oraz stylów CSS, więc jakiekolwiek zmiany, które chciałbyś wprowadzić, powinny być możliwe używając właśnie CSS. Przygotowaliśmy poradnik do CSS’a wykorzystywanego w adminie (en)

Jak mogę zacząć pisać kod do Django?

Dziękujemy że pytasz! Napisaliśmy cały dokument poświęcony odpowiedzi na te pytanie. Jest zatytułowany Contributing to Django (en).

Wrzuciłem poprawkę błędu w systemie ticet’ów kilka tygodni temu. Dlaczego ignorujecie moją poprawkę?

Nie martw się: Nie ignorujemy Cię!

Warto zrozumieć różnicę pomiędzy “ticket jest ignorowany” a “ticket nie został jeszcze rozpatrzony”. System ticketów Django zawiera setki otwartych ticketów o różnym wpływie na ostateczną funkcjonalność. Deweloperzy Django muszą je przejrzeć i określić ich priorytet.

Poza tym, jeżeli Twoja prośba o daną funkcjonalność nie ma szans na włączenie do Django, nie będziemy jej ignorować — po prostu zamkniemy ticket. Więc jeżeli Twój ticket jest ciągle otwarty, to nie oznacza, że Cię ignorujemy, po prostu nie mieliśmy jeszcze czasu, aby mu się przyjrzeć.