Django wyrosło z bardzo praktycznej potrzeby: World Online, projekt gazety internetowej, jest odpowiedzialne za budowanie rozległych aplikacji WWW na dziennikarskich deadline’ach. W dynamicznym newsroomie, World Online ma często tylko kilka godzin, aby skomplikowaną aplikację webową przeprowadzić od pomysłu do publicznego uruchomienia.
\nJednocześnie deweloperzy World Online Web stale są perfekcjonistami, jeśli chodzi o realizowanie najlepszych praktyk web dewelopmentu.
\nJesienią 2003 deweloperzy World Online (Adrian Holovaty i Simon Willison) porzucili PHP i zaczęli używać Pythona do rozwijania swoich stron. Tworząc rozległe, bardzo interaktywne witryny, takie jak Lawrence.com, zaczęli ekstrahować ogólny web-deweloperski framework, który pozwalał im budować aplikacje WWW coraz to szybciej. Usprawniali stale ten framework, przez dwa lata dodając poprawki.
\nLatem 2005 World Online postanowiło z-open-source’ować wynikowe oprogramowanie, Django. Django nie byłoby możliwe bez mnóstwa projektów open-source’owych – Apachea, Pythona i PostgreSQL-a, wymieniając tylko kilka – i jesteśmy zachwyceni mogąc oddać coś społeczności open-source.
\nDjango zostało nazwane imieniem Django Reinhardta, gitarzysty gypsy jazz z lat 30. do wczesnych 50. XX wieku. Do dnia dzisiejszego jest on uważany za jednego z najlepszych gitarzystów jazzowych wszechczasów.
\nPosłuchaj jego muzyki. Spodoba ci się.
\nDjango wymawia się jako dżan-go. Rymuje się z tan-go. Akcentujemy pierwszą sylabę.
\nNagraliśmy też klip audio z wymową.
\nTak, jest całkiem stabilne. Firmy takie jak Disqus, Instagram, Pinterest i Mozilla używają Django od wielu lat. Strony budowane na Django przetrwały skoki odwiedzin rzędu ponad 50 tysięcy odsłon na sekundę.
\nTak. W porównaniu z czasem developmentu, sprzęt jest tani. Właśnie dlatego Django jest zaprojektowane tak, aby wykorzystać jego potencjał tak bardzo, jak to możliwe.
\nDjango używa architektury „shared-nothing”, co oznacza, że możesz dodać zasoby sprzętowe na każdym poziomie – serwery baz danych, serwery cache’owania, czy serwery Web/aplikacji.
\nFramework czysto oddziela komponenty takie jak warstwa bazy danych i warstwa aplikacji. I dostarcza je w prostym-ale-potężnym frameworku cache’owania.
\nDjango został pierwotnie napisany w World Online, internetowym wydziale gazety w Lawrence w Kansas, w Stanach Zjednoczonych. Teraz Django jest tworzone przez międzynarodowy zespół wolontariuszy.
\nDjango udostępniony jest na 3-klauzulowej licencji BSD. Jest to licencja tzw. open source, która przydziela szeroki wachlarz uprawnień do modyfikacji i redystrybuowania Django.
\nDjango zawiera kod pochodzący z biblioteki standardowej Pythona. Python z kolei dystrybuowany jest na zasadach własnej licencji open source. Kopia licencji Pythona zawarta jest w Django dla zgodności z zasadami Pythona.
\nDjangoSites.org posiada stale rosnącą listę stron działających dzięki Django.
\nCóż, standardowe nazwy są sporne.
\nW naszej interpretacji MVC „widok” opisuje dane, które zostaną zaprezentowane użytkownikowi. Nie jest istotne jak dane wyglądają, ale kiedy są one prezentowane. Widok opisuje jakie dane widzisz, nie jak je zobaczyć. To subtelna różnica.
\nZatem w naszym przypadku „widok” to pythonowa funkcja callbackowa dla poszczególnego URL-a, gdyż ta właśnie funkcja definiuje, jakie dane są prezentowane.
\nPonadto, rozsądne jest odseparowanie zawartości od prezentacji – co realizowane jest przez szablony. W django „widok” opisuje, jakie dane są prezentowane, ale widok standardowo odwołuje się do szablonu, który opisuje jak dane są prezentowane.
\nGdzie w takim razie pasuje „kontroler”? W przypadku Django to najprawdopodobniej sam framework: machineria, która wysyła zapytanie do odpowiedniego widoku, na podstawie konfiguracji URL Django.
\nJeśli jesteś żądny akronimów, możesz mówić, że Django to framework „MTV” – to znaczy „model”, „szablon” („template”) i „widok” („view”). Taki podział nadaje o wiele więcej sensu.
\nW końcu chodzi o wykonywanie swojej roboty. I, niezależnie jak to nazwiemy, Django wykonuje robotę w sposób, który jest dla nas najlogiczniejszy.
\nWszyscy jesteśmy świadomi, że są dookoła inne niesamowite frameworki webowe i nie mamy awersji do pożyczania pomysłów tam, gdzie jest to właściwe. Jednakże Django powstało właśnie z powodu naszego niezadowolenia ze status quo, więc, prosimy, miej świadomość, że „dlatego, że <Framework X>to robi” nie jest wystarczającym powodem, aby dodać do Django daną funkcję.
\nGdy Django było pisane, Adrian i Simon spędzili trochę czasu przeszukując różne dostępne frameworki webowe.
\nNaszym zdaniem żaden z nich nie był wystarczająco dobrej jakości.
\nJesteśmy ostrożni. Możesz nawet nazwać nas perfekcjonistami. (Z deadline’ami.)
\nZ czasem natknęliśmy się na otwarte biblioteki, które robiły rzeczy, które już zaimplementowaliśmy. Uspokajający był fakt, że inni rozwiązują podobne problemy w podobny sposób, ale było za późno, aby integrować zewnętrzny kod: już napisaliśmy, przetestowaliśmy i zaimplementowaliśmy fragmenty naszego frameworka w kilku produkcyjnych rozwiązaniach – i nasz własny kod w sposób wyśmienity spełniał nasze oczekiwania.
\nW większości przypadków jednak okazywało się, że istniejące frameworki/narzędzia nieuchronnie miały jakieś fundamentalne, fatalne błędy, które uczyniły nas przeczulonymi. Żadne narzędzie nie pasuje do naszych filozofii w 100%.
\nTak jak mówiliśmy: Jesteśmy ostrożni.
\nUdokumentowaliśmy nasze filozofie na stronie filozofii projektowych.
\nNie, Django nie jest sam w sobie CMS-em, ani żadnym rodzajem „produktu pod klucz”. Jest frameworkiem webowym; narzędziem programistycznym, które pozwala ci budować witryny internetowe.
\nNa przykład nie ma wiele sensu porównywać Django do czegoś podobnego do Drupala, ponieważ Django jest czymś, co używasz, by tworzyć rzeczy takie jak Drupal.
\nTak, automatyczny panel administracyjny Django jest fantastyczny i pozwala oszczędzić czas – ale panel jest jednym modułem frameworka Django. Co więcej, pomimo że Django ma udogodnienia do budowania „CMS-owych” aplikacji, nie znaczy to, że jest mniej odpowiednie do budowania „nie-CMS-owych” aplikacji (cokolwiek to znaczy!).
\nDokumentacja Django jest dostępna w katalogu docs każdego wydania Django w archiwum tara. Ta dokumentacja jest w formacie reST (reStructuredText) i każdy plik tekstowy odpowiada stronie w oficjalnej witrynie Django.
Jako że dokumentacja jest przechowywana w kontroli wersji, możesz przeglądać zmiany dokumentacji tak samo jak zmiany w kodzie.
\nTechnicznie rzecz biorąc, dokumentacja na stronie Django jest generowana z ostatnich wersji rozwojowych tych dokumentów reST, więc dokumentacja na stronach Django może oferować więcej informacji niż dokumentacja, która jest załączona do najnowszego wydania Django.
\nTrudno jest podać oficjalny format cytowania z dwóch powodów: formaty cytowań mogą różnić się ogromnie między publikacjami, oraz standardy cytowania oprogramowania wciąż są przedmiotem pewnej debaty.
\nNa przykład styl APA, narzuciłby coś takiego:
\nDjango (Version 1.5) [Computer Software]. (2013). Retrieved from https://www.djangoproject.com/.\nJedynym prawdziwym przewodnikiem jest to, co zaakceptuje twój wydawca. Zdobądź więc kopię wskazówek wydawcy i wypełnij puste pola najlepiej jak możesz.
\nJeśli wskazówki stylu cytowań wymagają nazwy wydawcy, użyj „Django Software Foundation”.
\nJeśli potrzebujesz lokalizacji publikacji, użyj „Lawrence, Kansas”.
\nJeśli potrzebujesz adresu strony internetowej, użyj https://www.djangoproject.com/.
\nJeśli potrzebujesz nazwy, po prostu użyj „Django” bez żadnego sloganu.
\nJeśli potrzebujesz daty publikacji, użyj roku wydania wersji do której się odnosisz (np. 2013 dla v1.5)
\n