Este documento explica algumas filosofias que os desenvolvedores do Django tem usado ao criar o framework. Seu objetivo é de explicar o passado e guiar o futuro.
\nUm objetivo fundamental do Django é acoplamento fraco e coesão forte. As várias camadas do framework não devem “saber” uma das outras salvo se absolutamente necessário.
\nPor exemplo, o sistema de templates não tem conhecimento sobre requisições web; a camada de banco de dados não conhece nada sobre como mostrar dados e o sistema de views não se importa com qual sistema de templates o programador usa.
\nEmbora o Django venha com uma pilha de soluções completa por conveniência, as peças desta pilha de soluções são independentes uma das outras sempre que possível.
\nAplicações Django devem usar o mínimo possível de código; elas não devem ter código padrão. Django deve aproveitar as características dinâmicas do Python, como introspecção.
\nA questão dos frameworks web do século 21 é fazer com que aspectos enfadonhos do desenvolvimento web sejam rápidos. Django deve permitir que o desenvolvimento de aplicações web seja incrivelmente rápido.
\nCada conceito distinto e/ou dado deve estar em um, e apenas um, lugar. Redundância é ruim. Normalização é bom.
\nO framework deve deduzir, razoavelmente, o máximo possível do mínimo possível.
\n\nEsta é um dos princípios mais importantes de Python, listado em PEP 20, que significa que o Django não deve utilizar mágica demais. Mágica deve ser utilizada apenas quando houver uma razão realmente boa para tal. Mágica vale a pena ser usada somente se criar uma enorme conveniência, impossível de outra forma, e não deve ser implementada de forma a confundir os desenvolvedores que estejam tentando aprender como utilizar uma funcionalidade.
\nO framework deve ser consistente em todos os níveis. Consistência se aplica a tudo, do nível mais baixo (estilo de codificação Python utilizado) ao nível mais alto (a “experiência” de se usar Django).
\nCampos não devem assumir certos comportamentos baseados apenas no nome do campo. Isto requer muito conhecimento do sistema e é propenso a erros. Ao invés disso, o comportamento deve ser baseado em argumentos nomeados e, em alguns casos, no tipo do campo.
\nModelos devem encapsular cada aspecto de um objeto, seguindo o padrão de projeto Active Record de Martin Fowler.
\nEsse é o porque de ambos os dados representandos por um modelo e a informação sobre eles (seus nomes legíveis, opções como ordenação padrão, etc) são definidos na classe de modelo; toda a informação necessária para entender um dado modelo deveria ser amazenada no modelo.
\nOs objetivos principais da API de banco de dados são:
\nEle deveria executar comandos SQL o mínimo de vezes possível, e deveria otimizar os comandos internamente.
\nÉ por isso que desenvolvedores devem chamar save() explicitamente, ao invés do framework salvar coisas por trás das cenas silenciosamente.
É também por isso que o método select_related() QuerySet existe. É um opcional para melhorar a performance para casos comuns de seleção de “cada objeto relacionado”.
A API de banco de dados deve permitir uma rica, declarações expressivas na menor syntaxe possível. Não deve se basear na importação de outros módulos e objetos auxiliares.
\n“joins” devem ser realizados automaticamente, pode de trás das cenas, quando necessário.
\nCada objeto deve ser capaz de acessar cada objeto relaticionado, em todo o sistema. Este acesso deve funcionar nas duas vias.
\nA API do banco de dados deve perceber que é um atalho mas não necessariamente um meio para todos os fins. O framework deve facilitar a escrita de SQL personalizado – declarações inteiras, ou somente cláusulas WHERE personlizadas como parâmetros personalizados para chamadas de API.
As URLs na aplicação Django não devem estar casadas com os componentes Python. Amarrar URLs a nomes de funções Python é uma coisa ruim e feia.
\nAo longos destas linhas, o sistema de URL do Django deve permitir URLs ara uma mesma aplicação ser diferentes em diferetes contextos. Por exemplo, um site pode colocar “stories” em /stories/, enquanto outro possa usar /news/.
As URLs deve ser tão flexíveis quanto possível. Qualquer URL concebível deve ser permitida.
\nO framework deve tornar fácil (ou mesmo mais fácil) para um desenvolvedor definir URLs bonitas do que feias.
\nExtensões de arquivo em URLs de páginas web devem ser evitadas.
\nVírgula no estilo Vignette em URLs merecem uma punição servera.
\nTecnicamente, foo.com/bar e foo.com/bar/ são duas URLs diferentes, e os robôs de mecanismos de busca (e algumas ferramentas de análize de tráfego Web) podem tratá-las como páginas separadas. O Django deve fazer um esforço para “normalizar” as URLs então os robôs de mecânismos de buscas não ficam confusos.
Essa é a razão por de trás da definição APPEND_SLASH.
Nós vemos o sistema de “template” como uma ferramenta que controla a apresentação e a lógica relacionada a apresentação – e só isso. O sistema de template não deve dar suporte a funcionalidades que vão além deste objetivo básico.
\nA maioria dos sites web dinâmicos usam algum tipo de design para todo o site – um cabeçalho comum, um rodapé, barra de navegação etc. O sistema de “template” do Django deve tornar fácil armazenar estes elementos em um único local, eliminando duplicidade de código.
\nEsta é a filosofia por de trás: herança de template.
\nO sistema de “template” não deve ser feito de modo que só entregue HTML. Ele deve ser igualmente bom em gerar outros formatos baseados em texto, ou texto simples apenas.
\nUsar um mecanismo XML para interpretar templates introduz um mundo inteiro novo de erros humanos na edição de “templates” – e incorre em um nível de custo inaceitável no processamento de “template”.
\nO sistema de “template” não deve ser desenhado para que os “templates” sejam mostrados necessariamente de forma bonita em editores WYSIWYG como o dreamWeaver. Essa é uma limitação muito severa e não poderia permitir que a syntaxe fosse tão boa quanto é. O Django espera que autores de “templates” estejam confortáveis em editar o HTML diretamente.
\nO sistema de “template” não deve fazer coisas mágicas com espaços. Se um template inclui espaços, o sistema deve tratar espaços como trata o texto – somente mostrá-lo. Qualquer espaço em branco que não estiver dentro de uma tag de template deve ser mostrado.
\nO objetivo não é inventar uma linguagem de programação. O objetivo é oferecer somente o suficiente de funcionalidade programática, tal como ramificações e loops, que é essencial para tomar decisões relacionadas a apresentação. O Linguagem de Template do Django (sigla DTL em inglês) tenta evitar lógica avançada.
\nO sistema de “template” do Django reconhece que “templates” são na maioria das vezes escritos por designers, e não por programadores, e portanto não deve prezumir conhecimento em Python.
\nO sistema de template, tal como foi feito, deve coibir a inclusão de código malicioso – tal como comandos que deletam registros de banco de dados.
\nEste é outro motivo pelo qual o sistema de template não permite código Python arbitrário.
\nO sistema de “template” deve reconhecer que autores de “template” avançados talvez queiram extender sua tecnologia.
\nEsta é a filosofia por trás das “tags” e filtros personalizadas.
\nEscrever uma “view” deve ser tão simples quanto escrever uma função Python. Desenvolvedores não devem ter que instânciar uma classe enquanto uma função resolve.
\n“Views” devem ter acesso a um objeto de requisição – um objeto que armazena metadados sobre a requisição corrente. O objeto deve ser passado diretamente a uma função “view”, ao invés da função “view” ter que acessar os dados de uma requisição vindos de uma variável global. Isso faz com que seja leve, limpo e fácil de testar “views” passando um objeto de requisição “de mentira”.
\nUma “view” não deve se preocupar sobre qual sistema de template o desenvolvedor usa – ou mesmo se um sistema de templates está sendo usado.
\nGET e POST são distintintos; desenvolvedores devem usar explcitamente um ou outro. O framework tornar fácil a distinção entre dados de GET e POST.
\nO principais objetivos do Django framework de cache são:
\nO “cache” deve ser tão rápido quanto possível. Consequentemente, todo o código do framework em torno do “backend de cache” deve ser mantido no mínimo absoluto, especialmente para operações get().
A API de “cache” deve fornecer uma interface consistente através de “backends de cache” diferentes.
\nA API de “cache” deve ser extensível no nível da aplicação baseado nas necessidades dos desenvolvedores (por exemplo, veja Cache key transformation).
\n