このドキュメントでは、 Django の開発者たちがフレームワークの構築に取り入れ ている根本的な設計思想についていくつか解説します。それによって、 Django の これまでの経緯に説明を与えつつ、将来への指針にしたいと思います。
\nA fundamental goal of Django's stack is loose coupling and tight cohesion.\nThe various layers of the framework shouldn't "know" about each other unless\nabsolutely necessary.
\nFor example, the template system knows nothing about Web requests, the database\nlayer knows nothing about data display and the view system doesn't care which\ntemplate system a programmer uses.
\nAlthough Django comes with a full stack for convenience, the pieces of the\nstack are independent of another wherever possible.
\nDjango apps should use as little code as possible; they should lack boilerplate.\nDjango should take full advantage of Python's dynamic capabilities, such as\nintrospection.
\nThe point of a Web framework in the 21st century is to make the tedious aspects\nof Web development fast. Django should allow for incredibly quick Web\ndevelopment.
\nEvery distinct concept and/or piece of data should live in one, and only one,\nplace. Redundancy is bad. Normalization is good.
\nThe framework, within reason, should deduce as much as possible from as little\nas possible.
\n\nThis is a core Python principle listed in PEP 20, and it means Django\nshouldn't do too much "magic." Magic shouldn't happen unless there's a really\ngood reason for it. Magic is worth using only if it creates a huge convenience\nunattainable in other ways, and it isn't implemented in a way that confuses\ndevelopers who are trying to learn how to use the feature.
\nフレームワークはあらゆるレベルで一貫性を持たなければなりません。一貫性は、低レベル (採用する Python のコーディングスタイル) から高レベル (Django の使い方) までのあらゆる点で保たれなければなりません。
\nFields shouldn't assume certain behaviors based solely on the name of the\nfield. This requires too much knowledge of the system and is prone to errors.\nInstead, behaviors should be based on keyword arguments and, in some cases, on\nthe type of the field.
\nModels should encapsulate every aspect of an "object," following Martin\nFowler's Active Record design pattern.
\nThis is why both the data represented by a model and information about\nit (its human-readable name, options like default ordering, etc.) are\ndefined in the model class; all the information needed to understand a\ngiven model should be stored in the model.
\nデータベース API の主要な目的は、次のとおりです。
\nIt should execute SQL statements as few times as possible, and it should\noptimize statements internally.
\nThis is why developers need to call save() explicitly, rather than the\nframework saving things behind the scenes silently.
This is also why the select_related() QuerySet method exists. It's an\noptional performance booster for the common case of selecting "every related\nobject."
The database API should allow rich, expressive statements in as little syntax\nas possible. It should not rely on importing other modules or helper objects.
\nJoins should be performed automatically, behind the scenes, when necessary.
\nEvery object should be able to access every related object, systemwide. This\naccess should work both ways.
\nThe database API should realize it's a shortcut but not necessarily an\nend-all-be-all. The framework should make it easy to write custom SQL -- entire\nstatements, or just custom WHERE clauses as custom parameters to API calls.
URLs in a Django app should not be coupled to the underlying Python code. Tying\nURLs to Python function names is a Bad And Ugly Thing.
\nAlong these lines, the Django URL system should allow URLs for the same app to\nbe different in different contexts. For example, one site may put stories at\n/stories/, while another may use /news/.
URLs should be as flexible as possible. Any conceivable URL design should be\nallowed.
\nThe framework should make it just as easy (or even easier) for a developer to\ndesign pretty URLs than ugly ones.
\nFile extensions in Web-page URLs should be avoided.
\nVignette-style commas in URLs deserve severe punishment.
\nTechnically, foo.com/bar and foo.com/bar/ are two different URLs, and\nsearch-engine robots (and some Web traffic-analyzing tools) would treat them as\nseparate pages. Django should make an effort to "normalize" URLs so that\nsearch-engine robots don't get confused.
This is the reasoning behind the APPEND_SLASH setting.
私達は、テンプレートシステムはプレゼンテーションとプレゼンテーション関係のロジックを制御するためのツールであり、それ以上のものではないと考えています。 その本分をこえた機能をテンプレートシステムに求めるべきではありません。
\n大多数の動的な Web サイトでは、ヘッダやフッタ、ナビゲーションバーといった部分のデザインをサイト全体で共通にしています。 Django テンプレートシステムは、 こうしたサイトの構成要素を一箇所に保存しやすくし、重複したコードを削除する必要があります。
\nこれが テンプレートの継承 の背後にある思想です。
\nテンプレートシステムは、ただ単に HTML だけを出力するように設計されてはいません。他のテキストベースのフォーマットや、単純なプレインテキストも同じように上手く生成できるように作られています。
\nテンプレートをパースするのに XML エンジンを使ってしまうと、テンプレートの編集に全く新しいヒューマンエラーの世界を作り出してしまい、結果として、テンプレート処理に受け入れられないようなレベルの困難を生み出してしまうでしょう。
\n必ずしも Dreamweaver のような WYSIWYG エディタでうまく表示できるように テンプレートシステムを設計する必要はありません。そのような要求は制限が厳しすぎ、本来あるべきすっきりした構文を実現できなくなります。 Django では 直接 HTML を編集する作業に慣れたテンプレート作者を想定しています。
\nテンプレートシステムは、ホワイトスペースに対して変わった処理を行うべきではありません。もしテンプレートにホワイトスペースが書かれていれば、他の文字と同じように扱って、それをそのまま表示するべきです。テンプレートタグの外に書かれたすべてのホワイトスペースは、そのまま表示するべきです。
\n私たちの目的は、新しいプログラミング言語を開発することではありません。本当の目的は、プログラミング言語が持つような機能を必要十分なだけ使えるようにすることです。たとえば、条件分岐やループといったもので、これらはプレゼンテーションに関連する決定を下すときに大切になります。 Django テンプレート言語 (Django Template Language; DTL) は、複雑なロジックを使わずにこの目的を達成するために作られました。
\nDjango のテンプレートシステムは、テンプレートの書き手は プログラマー ではなく、主に デザイナー であることを念頭に置いています。そのため、Python の知識がまったくなくても書けるようになっています。
\nテンプレートシステムは、コマンドの実行やデータベースレコードの削除を行うような、悪意のあるコードの挿入ができないようになっていなければなりません。
\nこれが、テンプレートシステムが任意の Python コードの実行を許さないようにできているもう一つの理由です。
\nテンプレートシステムは、高度なテンプレート作者によるテクノロジの拡張に配慮せねばなりません。
\nこれが、カスタムテンプレートタグとフィルタの背後にある思想です。
\nビューは、Python の関数を書くのと同じくらい簡単に書けるべきです。開発者は、ふつうに関数を書くときと同じように、クラスからインスタンスを作ったりせずにビューが書けるべきです。
\nビューはリクエストオブジェクトにアクセスします。リクエストオブジェクトとは、 現在のリクエストに関するメタデータを入れるオブジェクトです。ビューはこのオブジェクトをグローバル変数経由でアクセスするのではなく、引数として直接受け取るようにすべきです。それにより、「偽の」リクエストオブジェクトを渡してビューを簡単かつクリーンにテストできるようになります。
\nビューは、開発者がどのテンプレートシステムを使用しているか意識せずに使えるべきです。もっと言えば、テンプレートシステム自体を使っているかどうかも気にせずに使えるようにするべきです。
\nGET と POST は区別します。開発者は明示的に一方を他方と区別して明示的に使用するべきです。フレームワークは、GET と POST データを分かりやすく区別できるようにしなければなりません。
\nDjango の キャッシュフレームワーク の主な目的は次の点にあります。
\nキャッシュは可能な限り高速でなければならない。したがって、キャッシュバックエンドを包んでいるフレームワークのコード (特に get() 操作) はすべて、極限まで短くするべきである。
キャッシュ API は、バックエントが違っていても一貫したインターフェイスを提供するべきである。
\nキャッシュ API は、開発者のニーズにもとづいて、アプリケーションレベルで拡張可能であるべきである (例としては Cache key transformation がある)。
\n