Философия Django.
(перевод nerezus)
Этот документ соответствует SVN-версии Django, которая может значительно отличаться от предыдущих версий.

Этот документ объясняет часть фундаментальных принципов, которые разработчики Django использовали в создании фреймворка. Его цель состоит в том, чтобы объяснить прошлое и показать будущее.

Обзор

Свободное сцепление

Фундаментальная цель набора компонентов Django - свободное сцепление и полное единство. Различные уровни фреймворка не должны "знать" друг о друге за исключением случаев, когда это действительно необходимо.
 
Например, шаблонизатор ничего не знает о Web-запросах, база данных не знает ничего об отображении данных, а система представления не заботится, какой шаблонизатор использует программист.
 
Хотя Django идет с полным набором компонентов для удобства, части его независимы от друга везде, где возможно.

Меньше кода

Приложения Dango должны использовать настолько мало кода, насколько это возможно.
Django должен использовать преимущества динамических возможностей Python, таких как самоанализ (introspection).

Быстрая разработка

Целью веб-фреймворка в 21 веке является сделать утомительные аспекты веб-разработки быстрыми.
Django должен учитывать невероятно быструю веб-разработку .


Не повторяйте себя (Don’t repeat yourself, DRY)

Каждое отличное понятие и/или часть данных должны находиться в одном, и только в одном месте. Избыточность – это плохо, а нормализация - хорошо. Безусловно, фреймворк  должен вывести максимально возможное количество информации из как можно малого. 

Явный лучше чем неявный

Это основной принцип Python’а, означающий, что Django не должен сделать слишком большого количества "магии". Магия не должно происходить, если нет действительно серьезного основания для этого. Магию стоит использовать, только если это делает разработку настолько удобной, что это недосягаемо другими способами. И если это не осуществляется способом, смущающим разработчиков, которые захотят узнать, как использовать эту особенность.

Последовательность

Фреймворк должен быть последовательным на всех уровнях. Последовательность должна относиться ко всему от низкого уровня (стиль кодирования, используемый в Python) до высокого (опыт использования Django).

Модели

Явный лучше чем неявный

Поля не должны предполагать определенные поведения, базируемые исключительно на названии этого поля. Это требует слишком большого знания системы и имеет склонность к ошибкам. Вместо этого поведения должны быть основанными на параметрах ключевых слов и, в некоторых случаях, на типах полей.

Включите всю уместную логику домена

Модели должны инкапсулировать каждый аспект объекта, соблюдая Active Record – шаблон проектирования Мартина Фаулера.

Это причина, по которой определенные для модели опции администратора  включены в модель непосредственно; данные, связанные с моделью должны быть сохранены в модели.

API базы данных

Основные цели API базы данных:
Эффективность SQL

SQL-запросы должны выполняться за минимальное время и должны оптимизироваться внутренними средствами.
 
Именно поэтому разработчик должен явно вызывать save() вместо того, чтобы фреймворк занимался этим «за сценой».

И именно поэтому существует метод select_related() для QuerySet. Это дополнительное средство увеличения производительности для общего случая для связанных объектов.

Краткий, мощный синтаксис

API базы данных должен позволять выразительные определения при помощи как можно меньшего кода. API не должен полагаться на импортирование других или вспомогательных объектов.

Объединения(joins) должны быть выполнены автоматически и негласно, когда это необходимо.

Каждый объект должен иметь возможность обратиться к каждому связанному объекту, и это правило должно выполняться для всех объектов системы. Этот доступ должен работать двунаправлено.

Возможность непринужденного использования SQL, когда необходимо

API  базы данных должен реализовать не только обращение с моделью, но и возможность использования только низкоуровневых методов. Фреймворк должен облегчить написание SQL, как запросов в целом, так и отдельных их частей типа WHERE с произвольными параметрами вызовов API.

 Дизайн URL

Свободное сцепление

URL в приложениях Django не должны быть связаны с низлежащим кодом. Связывание URL с именами функции Python - Плохая И Уродливая Штука.

Согласно этим строкам, система URL Django должна позволить URL быть разними для одного и того же приложения в различных контекстах. Например, один сайт может поместить истории в /stories /, в то время как другой может использовать/news/.

Бесконечная гибкость

URL должны быть настолько гибкими, насколько возможно. Возможен абсолютно любой мыслимый дизайн URL.

Поощрение лучших методов

Фреймворк должен позволить разработчику легче работать с красивыми URL, чем с некрасивыми.
 
Расширений файла в URL Web-страницы нужно избегать.

Запятые в URL заслуживают серьезного наказания.

Определенные URL

Технически, foo.com/bar и foo.com/bar/ - два различных URL, и роботы поискового сервера (и некоторые инструменты анализа трафика Сети) обработали бы их как отдельные страницы. Django должен предпринять усилие "нормализовать" URL так, чтобы роботы поискового сервера не запутались.
Это решается с помощью установки APPEND_SLASH в настройках.

Шаблонизатор

Разделение логики и представления

Мы видим шаблонизатор инструментом, который управляет представлением и связанной с представлением логикой – и все. Система шаблона не должна поддержать функциональные возможности, которые выходят за пределы этой основной  цели.

Если бы мы хотели поместить все в шаблоны, то мы использовали бы PHP. Используй его, делая это, если хочешь.

Препятствуйте избыточности

Большинство динамических вебсайтов использует своего рода обычный дизайн - обычный заголовок, нижний колонтитул, навигационную полосу, и т.д. Шаблонизатор Django должен облегчить хранение элементов в отдельном месте, устраняя лишний код.

Это философия наследования шаблонов.

Будьте отдалены от HTML

Шаблонизатор не должен быть спроектирован так, чтобы его единственной целью был только вывод HTML. Он  должен быть одинаково хорошим при производстве других форматов на основе текста, даже для plaintext.

XML не должен использоваться для языков шаблона.

Использование  механизма XML для парсинга шаблонов открывает целый новый мир ошибок, обусловленных человеческим фактором. И подвергается недопустимому уровню избыточности(overhead) в обработке шаблонов.

Примите за факт компетентность проектировщика

Система шаблона не должна быть проектирована так, чтобы шаблоны обязательно были отображены  читаемо в WYSIWYG редакторах, типа Dreamweaver. Это слишком сложно из-за ограничений и не позволило бы синтаксису быть столь же хорошим, каким он является. Django ожидает, что авторы шаблона могут редактировать HTML непосредственно.

Обработайте пустые места очевидным образом.

Шаблонизатор не должен заниматься магией. Если шаблон включает пустые места(пробельные символы и прочее), система должна обработать их, система должна считать пустые места обычным текстом. Любое пустое место, которое не находится в тэге шаблона, должно быть отображено.

Не изобретайте язык программирования

Система шаблона преднамеренно не позволяет следующее:
Определение переменных
Продвинутую логику

Цель состоит не в том, чтобы изобрести язык программирования. Цель состоит в том, чтобы предложить только достаточно функциональных возможности, типа  условий, циклов, которые является необходимым для представления.

Шаблонизатор Django осознает, что шаблоны чаще всего написаны проектировщиками, а не программистами, и поэтому не требует знания Python.

Безопасность

Система шаблона сразу «из коробки» должна запретить включение враждебного программного кода, типа команд, которые удаляют записи базы данных.

Это другая причина, по которой шаблонизатор не позволяет использовать код Python в шаблонах.

Расширяемость

Система шаблона должна принимать во внимание, что продвинутые авторы шаблонов могут захотеть расширить эту технологию.

Это философия Django о дополнительных  тэгах шаблонов и фильтров.

Представление

Простота

Написание представлений должно быть столь же простым, как написание функций Python. Разработчикам не придется заморачиваться с классами, когда можно будет обойтись функциями. 

Использование объектов запроса(request)

Представления должны иметь доступ к объекту запроса(request) - объекту, который хранит метаданные о текущем запросе. Объект должен быть передан в функцию представления непосредственно вместо того, чтобы эта функция имела доступ к запросу через глобальные переменные. Благодаря этому достигается легкость, чистота и гибкость тестирования представлений при помощи передачи им поддельных  объектов запроса. 

Свободное сцепление

Представление не должно заботиться о том, какой шаблонизатор использует разработчик или вообще о том, используется ли вообще  шаблонизатор.

Различайте GET и POST

GET и POST  различны, разработчики должны явно использовать один или другой. Фреймворк должен с легкостью различать GET и POST данные.

Ты извини конечно, но перевод просто кошмарный. Как будто просто Google Translat'ом перевёл.
Его бы просто не таким "машынным" сделать, что ли.

это был первый опыт... и скорее всего последний, т.к. процесс мне нереально не понравился (
Рассказали технологию правильного перевода: несколько раз перечитать и пересказать своими словами. В зависимости от выбранного размера блоков текст колеблется между свободным пересказом и "машинным переводом", и надо подобрать оптимальный размер.

Нормальный перевод.   
Кстати Django-book уже то-же перевели на русский, правда мне оригинал читать проще   

Он, скажем так, понятный.
В печтление собственно портит только такие вот моменты

Если их поправить - будет ок.
А насчёт "последнего" опыта - это зря, переводы штука полезная, особенно для переводчика 
Начинание-то отличное.