Detta dokument förklarar några av de grundläggande filosofier som Djangos utvecklare har använt för att skapa ramverket. Dess mål är att förklara det förflutna och vägleda framtiden.
\nEtt grundläggande mål för Djangos stack är lös koppling och tät sammanhållning. De olika lagren i ramverket ska inte ”veta” om varandra om det inte är absolut nödvändigt.
\nMallsystemet vet t.ex. ingenting om webbförfrågningar, databaslagret vet ingenting om datavisning och visningssystemet bryr sig inte om vilket mallsystem en programmerare använder.
\nÄven om Django levereras med en komplett stack för enkelhetens skull, är delarna av stacken oberoende av varandra där det är möjligt.
\nDjango-appar ska använda så lite kod som möjligt; de ska sakna boilerplate. Django bör dra full nytta av Pythons dynamiska funktioner, till exempel introspektion.
\nPoängen med ett webbramverk på 2000-talet är att göra de tråkiga aspekterna av webbutveckling snabba. Django bör möjliggöra otroligt snabb webbutveckling.
\nVarje distinkt begrepp och/eller uppgift bör finnas på en och endast en plats. Redundans är dåligt. Normalisering är bra.
\nRamverket bör, inom rimliga gränser, härleda så mycket som möjligt från så lite som möjligt.
\n\nDetta är en grundläggande Python-princip som listas i PEP 20, och det innebär att Django inte ska göra för mycket ”magi” Magi bör inte hända om det inte finns en riktigt bra anledning till det. Magi är värt att använda endast om det skapar en enorm bekvämlighet som inte kan uppnås på andra sätt, och det implementeras inte på ett sätt som förvirrar utvecklare som försöker lära sig hur man använder funktionen.
\nRamverket bör vara konsekvent på alla nivåer. Konsistens gäller allt från låg nivå (den Python-kodningsstil som används) till hög nivå (”upplevelsen” av att använda Django).
\nFält bör inte anta vissa beteenden enbart baserat på fältets namn. Detta kräver för mycket kunskap om systemet och är felbenäget. Istället bör beteenden baseras på nyckelordsargument och, i vissa fall, på fältets typ.
\nModeller ska kapsla in alla aspekter av ett ”objekt”, enligt Martin Fowlers designmönster Active Record.
\nDet är därför som både de data som representeras av en modell och information om den (dess mänskligt läsbara namn, alternativ som standardordning etc.) definieras i modellklassen; all information som behövs för att förstå en viss modell bör lagras i modellen.
\nDe viktigaste målen för databas-API:et är:
\nDen ska exekvera SQL-satser så få gånger som möjligt och den ska optimera satserna internt.
\nDet är därför som utvecklare måste anropa save() explicit, i stället för att ramverket sparar saker bakom kulisserna i tysthet.
Det är också därför som metoden select_related() `` ``QuerySet finns. Det är en valfri prestandaförstärkare för det vanliga fallet att välja ”varje relaterat objekt”
Databas-API:et bör tillåta omfattande, uttrycksfulla uttalanden med så lite syntax som möjligt. Det ska inte vara beroende av import av andra moduler eller hjälpobjekt.
\nSammanfogningar bör utföras automatiskt, bakom kulisserna, när det behövs.
\nVarje objekt bör kunna komma åt alla relaterade objekt i hela systemet. Denna åtkomst bör fungera åt båda hållen.
\nDatabas-API:et bör inse att det är en genväg, men inte nödvändigtvis en universallösning. Ramverket bör göra det enkelt att skriva anpassad SQL - hela uttalanden eller bara anpassade WHERE-klausuler som anpassade parametrar till API-anrop.
URL:er i en Django-app ska inte kopplas till den underliggande Python-koden. Att binda webbadresser till Python-funktionsnamn är en dålig och ful sak.
\nI linje med detta bör Djangos URL-system tillåta att URL:er för samma app kan vara olika i olika sammanhang. Till exempel kan en webbplats lägga berättelser på /stories/, medan en annan kan använda /news/.
URL:er bör vara så flexibla som möjligt. Alla tänkbara utformningar av webbadresser bör tillåtas.
\nRamverket bör göra det lika enkelt (eller till och med enklare) för en utvecklare att skapa snygga webbadresser som fula.
\nFiltillägg i webbsidors URL:er bör undvikas.
\nVignettliknande kommatecken i webbadresser förtjänar stränga straff.
\nTekniskt sett är foo.com/bar och foo.com/bar/ två olika webbadresser, och sökmotorrobotar (och vissa verktyg för analys av webbtrafik) skulle behandla dem som separata sidor. Django bör anstränga sig för att ”normalisera” webbadresser så att sökmotorrobotar inte blir förvirrade.
Detta är resonemanget bakom inställningen APPEND_SLASH.
Vi ser ett mallsystem som ett verktyg som kontrollerar presentation och presentationsrelaterad logik - och det är allt. Mallsystemet bör inte stödja funktionalitet som går utöver detta grundläggande mål.
\nDe flesta dynamiska webbplatser använder någon form av gemensam design för hela webbplatsen - en gemensam sidhuvud, sidfot, navigeringsfält osv. Djangos mallsystem bör göra det enkelt att lagra dessa element på ett enda ställe, vilket eliminerar dubbel kod.
\nDetta är filosofin bakom template inheritance.
\nMallsystemet bör inte vara utformat så att det bara genererar HTML. Det bör vara lika bra på att generera andra textbaserade format, eller bara vanlig text.
\nAtt använda en XML-motor för att analysera mallar innebär en helt ny värld av mänskliga fel vid redigering av mallar - och en oacceptabel nivå av overhead vid mallbearbetning.
\nMallsystemet bör inte utformas så att mallar nödvändigtvis visas snyggt i WYSIWYG-editorer som Dreamweaver. Det är en alltför allvarlig begränsning och skulle inte tillåta syntaxen att vara så fin som den är. Django förväntar sig att mallförfattare är bekväma med att redigera HTML direkt.
\nMallsystemet bör inte göra magiska saker med blanksteg. Om en mall innehåller blanksteg bör systemet behandla blanksteget som text - bara visa det. Alla blanksteg som inte finns i en malltagg ska visas.
\nMålet är inte att uppfinna ett programmeringsspråk. Målet är att erbjuda precis tillräckligt med programmeringsliknande funktionalitet, såsom förgrening och looping, som är nödvändig för att fatta presentationsrelaterade beslut. Django Template Language (DTL) syftar till att undvika avancerad logik.
\nMallsystemet bör i utgångsläget förbjuda införandet av skadlig kod - till exempel kommandon som raderar databasposter.
\nDetta är ytterligare ett skäl till att mallsystemet inte tillåter godtycklig Python-kod.
\nMallsystemet bör vara medvetet om att avancerade mallförfattare kan vilja utöka dess teknik.
\nDetta är filosofin bakom anpassade malltaggar och filter.
\nAtt skriva en vy borde vara lika enkelt som att skriva en Python-funktion. Utvecklare ska inte behöva instansiera en klass när det räcker med en funktion.
\nVyer bör ha tillgång till ett request-objekt - ett objekt som lagrar metadata om den aktuella förfrågan. Objektet bör skickas direkt till en vyfunktion, i stället för att vyfunktionen måste komma åt förfrågningsdata från en global variabel. Detta gör det lätt, rent och enkelt att testa vyer genom att skicka in ”falska” request-objekt.
\nEn vy bör inte bry sig om vilket mallsystem utvecklaren använder - eller ens om ett mallsystem används överhuvudtaget.
\nGET och POST är olika; utvecklare bör uttryckligen använda det ena eller det andra. Ramverket bör göra det lätt att skilja mellan GET- och POST-data.
\nDe centrala målen för Djangos cache-ramverk är:
\nA cache should be as fast as possible. Hence, all framework code surrounding\nthe cache backend should be kept to the absolute minimum, especially for\nget() operations.
Cache-API:et bör tillhandahålla ett konsekvent gränssnitt för de olika cache-backends.
\nCache-API:t bör vara utbyggbart på applikationsnivå baserat på utvecklarens behov (se t.ex. Transformation av cache-nyckel).
\n