7

私はDjangoサイトで簡単なポーリングチュートリアルを行っていましたが、最後のトピックは一般的なビューの紹介です。すべてのURLパターンに対してカスタムビューを作成する必要性を回避する便利な方法。

私が理解している限り、これが主なアイデアです。

1）リクエスト->URLパターン->表示->テンプレート

また

2）リクエスト-> URLパターン（汎用ビュー）[->オプションのテンプレート]

2は必要なコードが少ないようで、4つではなく2つのステップしかありませんが、欠点として、URLパターンにより多くのものを貼り付け、より多くの自動マジックが行われ、ビューが2か所で定義されるようになりました。

私はURLパターンをそれだけにするというアイデアが本当に好きです-パターンであり、追加の定型文を追加しないでください。また、単純なビューも含めてすべてのビューを明示的に定義するというアイデアも気に入っています。これにより、後でファイルを行き来することなく、すべてのビューを見つけることができます。さらに、automagicは、最初から（少なくともDjangoの最初から）作成するものよりもカスタマイズが難しいことは誰もが知っています。

私は何かが足りないのですか？後で一般的なビューをまったく使用しないことに悩まされるような大きな間違いをしているのでしょうか。

4

3 に答える 3

10

Generic Viewsの目的は、複数のビューで同様のコードを繰り返し使用する場合の定型コードを減らすことです。あなたは本当にそれだけのためにそれを使うべきです。基本的に、djangoが一般的に行っていることを許可しているからといって、それを行うべきではありません。特に、コードが自分の好みに合わなくなった場合はそうではありません。

django-1.3のクラスベースビューを使用している場合は、の関数に多くの変数を渡す代わりにurls.py、関心のあるそれぞれのメソッドをオーバーライドできます。これにより、両方の長所が提供されます。-コードが減り、制御が強化されます。

于 2011-06-26T17:11:35.377 に答える
3

一般的なビューを使用するかどうかは、あなたの特権です。繰り返しビューロジックをコーディングしていることに気付くかもしれませんが、問題は発生しません。ラップされた/サブクラス化された汎用ビューをviews.pyで使用することを検討してください（多くの場合、とにかくそれらをカスタマイズする必要があります）。これにより、ボイラープレートがurls.pyから除外され、すべてのビューが同じ場所に配置されます。

于 2011-06-26T16:29:22.533 に答える
2

django 1.2では、一般的なビューを使用していますが、URLではなく「通常の」ビュー内にあります。

#views.py
import generic_views

def my_generic_list(request):
    qs = Something.objects.filter(some arguments)
    return generic.object_list(queryset = qs, ... other stuff, usually extra_context)

このように（imo）ビューは非常にシンプルですが、変更があった場合に「実際のビュー」になることができますが、urls.pyはクリーンなままです。

于 2011-06-26T20:40:23.340 に答える