django.contrib.staticfiles
テンプレートを整理するのと同じ方法で静的(画像、js、cssなど)を整理できるようになりました:アプリケーションフォルダー(特に個々のdjangoアプリケーションに便利)またはプロジェクトフォルダーに保持し、ファイルの一部を再定義し、他の部分はそのままにします、ユーザーがファイルを配置する場所や保存場所(別のサーバー?アマゾンs3?)を心配せずにファイルを参照するため、これらのファイルを「探して」適切な場所にコピーする必要がなくなりました。
現在、管理パネルの静的なハッキングも過去に考慮することができます。django.contrib.staticfilesを使用するだけであれば問題はありません。
テスト中
Unittest2は現在jungに存在し 、django.test.TestCaseはunittest2.TestCaseを継承しています。 つまり、unittest2のすべての新機能を使用して、jungaのテストを作成できます。 たとえば、事前にテストを記述して、expectedFailureデコレータでマークを付けることができます。 または、テストをスキップする条件を指定します(たとえば、mysqlに固有のテストで、sqliteの下で合格しないもの)。 または、新しいアサートを使用します。
もちろん、以前はunittest2を配置して使用することもできましたが、ベースが必要になり、django.test.TestCaseを継承する必要がある場合には役に立ちませんでした。
assertNumQueriesのようなさまざまな便利なものもあります。
フォーリンキー
今、誰かがFKを介して参照したオブジェクトを削除すると、参照されたオブジェクトは必ずしも削除されません。 カスケード削除を構成し 、NULLまたはデフォルト値にリセットし、例外を呼び出し、何もしない(データベースに自ら決定させる)ことができます 。
パターン
しばしば書いた
{% with foo as bar %} {% include "my_template.inc.html" %} {% endwith %}
またはそのような作品の包含タグ? これは必要ありません。インクルージョンタグの束を捨てることができます:
{% include "my_template.inc.html" with bar=foo %}
+タグライブラリから個別のタグのみをダウンロードできます。 変数はurlに渡すことができます。 withタグも簡略化されています。 simple_tagで作成されたタグは、コンテキストを取ることを学びました。
キャッシング
同時に複数のキャッシュがサポートされています(たとえば、一部のデータはlocalmemキャッシュに格納でき、一部はmemcached /データベースに格納できます。また、一部の場合は、無効化と同時再生に対する保護を備えた「スマート」キャッシュバックエンドを使用します。
さらに、キャッシングバックエンドを備えたさまざまなサードパーティアプリケーションから有用な機能がクロールされました:すぐに使用できるグローバルプレフィックス(複数のプロジェクトがキーの競合を避けるために1つのmemcachedを使用する場合に必要)、キャッシュバージョン(サイトの更新、およびキャッシュ内の古いデータのサポート)現在どのフォーマットが間違っていますか?現在のバージョンのキャッシュを増やします)、キー変換(トリッキーな無効化スキームが必要ですか?実装します)、pylibmcのサポート、パラメーター付きのGETリクエストのキャッシュ。
ロギング
Pythonロギングとの統合が可能になりました。 settings.pyでは、ロギングを柔軟に構成できます。 500エラーの電子メールの送信は、最終的にログ記録によっても行われます。
視聴回数
ビューを作成するためのさまざまなユーティリティが多数登場しています。
クラスベースのビュー。
ビュークラスを記述できるようになりました。 私にとっては、なぜそうなっているのかまだ理解できていません。 「大きな」部分や、他の場所で拡張する必要のある混乱したロジックを持つある種の複雑なもの(宣言型API、ユニバーサル管理者のようなもの)に使用する価値があるでしょう。 拡張が容易になるように、標準の汎用ビューがクラスで書き換えられました。
TemplateResponse
通常のビュー機能を拡張するために、ジャングルにTemplateResponseが追加されました。 TemplateResponseは、最後の瞬間にのみ結果をレンダリングする(テンプレートのコンテキストを置換する)遅延HttpResponseです。 関数がTemplateResponseを返す場合、テンプレートを置き換えたり、コンテキストを変更(および読み取り)したり、まったく異なるものを返したりできます(元の応答をレンダリングするオーバーヘッドなしで)。 このことは、リリースノートでスキップして、柔軟性のためにクラスのビューをラップし始めるのは非常に簡単です。例:
# # from django.template.response import TemplateResponse from parrots.models import Parrot def parrot_list(request): parrots = Parrot.objects.all() # RequestContext. # render_to_template direct_to_template . return TemplateResponse(request, 'parrots.html', {'parrots': parrots})
# . # parrot_list ( , ), # , import parrots.views def parrot_list(request, color) # , response = parrots.views.parrot_list(request) # (TemplateResponse ), # (QuerySet ) # - , , response.template_name = 'my_parrots.html' # original_parrots = response.context_data['parrots'] # , response.context_data['parrots'] = original_parrots.filter(color=color).select_related('owner') # - response.context_data['foo'] = 'bar' # return response
汎用ビューは
UPD :希望的観測、django.contrib.admin TemplateResponseからのビューは返されません! チケットはハングしていますが、リリースすることはコミットされていません。
django.shortcuts.render
# , from django.shortcuts import render def parrot_list(request): parrots = Parrot.objects.all() # render_to_response direct_to_template return render(request, 'parrots.html', {'parrots': parrots})
それだけではありません:これらの変更に加えて、i18nとl10nでの作業が改善され、マット全体がコードから削除されました。他にも目立たない多くの変更とアーキテクチャの改善があります 。