Filosofias de ProjetoLink para este cabeçalho#

Acoplamento fracoLink para este cabeçalho#

Um 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.

Por exemplo, o sistema de modelo não sabe nada sobre solicitações da web, a camada de banco de dados não sabe nada sobre exibição de dados e o sistema de exibição não se importa com qual sistema de modelo um programador usa.

Embora 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.

Menos códigoLink para este cabeçalho#

Aplicaçõ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.

Desenvolvimento RápidoLink para este cabeçalho#

O objetivo de uma estrutura da Web no século 21 é tornar rápidos os aspectos tediosos do desenvolvimento da Web. O Django deve permitir um desenvolvimento web incrivelmente rápido.

Não repita a si mesmo (DRY)Link para este cabeçalho#

Cada conceito distinto e/ou dado deve estar em um, e apenas um, lugar. Redundância é ruim. Normalização é bom.

O framework deve deduzir, razoavelmente, o máximo possível do mínimo possível.

Explícito é melhor que implícitoLink para este cabeçalho#

Esta é 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.

ConsistênciaLink para este cabeçalho#

O 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).

Explícito é melhor que implícitoLink para este cabeçalho#

Campos 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.

Inclui toda lógica do domínio relevanteLink para este cabeçalho#

Modelos devem encapsular cada aspecto de um objeto, seguindo o padrão de projeto Active Record de Martin Fowler.

Esse é 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.

Eficiência SQLLink para este cabeçalho#

Ele deveria executar comandos SQL o mínimo de vezes possível, e deveria otimizar os comandos internamente.

É por isso que desenvolvedores devem chamar save() explicitamente, ao invés do framework salvar coisas por trás das cenas silenciosamente.

This is also why the FETCH_PEERS fetch mode exists. It’s an optional performance booster for the common case of selecting related objects for every peer in a QuerySet.

Concisa, sintaxe poderosaLink para este cabeçalho#

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.

“joins” devem ser realizados automaticamente, pode de trás das cenas, quando necessário.

Cada objeto deve ser capaz de acessar cada objeto relaticionado, em todo o sistema. Este acesso deve funcionar nas duas vias.

Opção de usar SQL nativo, quando necessário.Link para este cabeçalho#

A 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.

Acoplamento fracoLink para este cabeçalho#

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.

Ao 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/.

Flexibilidade InfinitaLink para este cabeçalho#

As URLs deve ser tão flexíveis quanto possível. Qualquer URL concebível deve ser permitida.

Encoraja melhores práticasLink para este cabeçalho#

O framework deve tornar fácil (ou mesmo mais fácil) para um desenvolvedor definir URLs bonitas do que feias.

Extensões de arquivo em URLs de páginas da web devem ser evitadas.

Vírgula no estilo Vignette em URLs merecem uma punição servera.

URLs definitivasLink para este cabeçalho#

Tecnicamente, foo.com/bar e foo.com/bar/ são dois URLs diferentes, e os robôs do mecanismo de busca (e algumas ferramentas de análise de tráfego da web) os tratariam como páginas separadas. O Django deve fazer um esforço para “normalizar” as URLs para que os robôs dos mecanismos de busca não fiquem confusos.

Essa é a razão por de trás da definição APPEND_SLASH.

Separe a lógica da apresentação.Link para este cabeçalho#

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.

Desencoraja a redundânciaLink para este cabeçalho#

A 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.

Esta é a filosofia por de trás: herança de template.

Esteja desacomplado do HTML.Link para este cabeçalho#

O 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.

XML não deve ser usado para linguagens de “template”.Link para este cabeçalho#

Usar 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”.

Assume a competência do designerLink para este cabeçalho#

O 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.

Trate espaços em branco de maneira óbvia.Link para este cabeçalho#

O 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.

Não inventa uma linguagem de programaçãoLink para este cabeçalho#

O 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.

SegurançaLink para este cabeçalho#

O 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.

Este é outro motivo pelo qual o sistema de template não permite código Python arbitrário.

ExtensibilidadeLink para este cabeçalho#

O sistema de “template” deve reconhecer que autores de “template” avançados talvez queiram extender sua tecnologia.

Esta é a filosofia por trás das “tags” e filtros personalizadas.

SimplicidadeLink para este cabeçalho#

Escrever 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.

Use objetos de requisiçãoLink para este cabeçalho#

“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”.

Acoplamento fracoLink para este cabeçalho#

Uma “view” não deve se preocupar sobre qual sistema de template o desenvolvedor usa – ou mesmo se um sistema de templates está sendo usado.

Diferencie entre GET e POST.Link para este cabeçalho#

GET 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.

Menos códigoLink para este cabeçalho#

A cache should be as fast as possible. Hence, all framework code surrounding the cache backend should be kept to the absolute minimum, especially for get() operations.

ConsistênciaLink para este cabeçalho#

A API de “cache” deve fornecer uma interface consistente através de “backends de cache” diferentes.

ExtensibilidadeLink para este cabeçalho#

A API de “cache” deve ser extensível no nível da aplicação baseado nas necessidades dos desenvolvedores (por exemplo, veja Cache key transformation).