問題タブ [django-class-based-views]

特定のディレクトリの下にあるすべてのテンプレートを表示する TemplateView を作成したいと思います。

たとえば、私は

...

(もっとたくさん)

私のurls.pyには..

..

私のviews.pyには

ただし、誰かが URL /staticpages/blahblah.html (存在しない) にアクセスすると、このビューによって受け入れられ、テンプレートが見つからないというエラーが生成されます。テンプレートが見つからない場合、どうすれば 404 にリダイレクトできますか?

または、これを行うより良い方法はありますか？

持っているアプリを 1.1 から 1.3 に移行し始めたところです。

私はクラスベースのビューの厚さに入り始めており、吹き飛ばされていますが、あまり良い方法ではありません.
いくつかの不満がありますが、ここでの具体的な質問は次のとおりです。

これは、一般的なクラスベースのビューで url テンプレート タグを使用できる唯一の方法ですか?
クラスベースのビューへのパラメータを持つDjango逆URL、
つまりすべてのURLエントリに名前を付ける必要がありますか?

Django の基本的な哲学の 1 つは DRY ですが、ここにいるのはばかげているように思えます.... RY-ing.....

前もって感謝します。

編集：
だから私はhttps://gist.github.com/1877374を持っています

レンダリング中に TemplateSyntaxError Caught NoReverseMatch: Reverse for 'views.HomeView.as_view' with Arguments '()' and keyword arguments '{}' not found というエラーが発生します。

これを間違って使用していますか？

Tangent: urls.py ファイル内のすべてのエントリ
に 名前を付ける必要がある場合、なぜ RY を使用していると私が考えるのかについて、もう少し説明したいと思います。

私の urls.py は通常 https://gist.github.com/1877462のようになります

デカップリングについては完全に理解しています。
ここでのポイントは、必要なときにそうする能力があるということです。必要なときは、名前機能を絶対に使用します。それ以外の場合、view.py のクラス/機能の名前と同じになることが多いのに、すべてのエントリに冗長に URL を追加し、すべてのエントリに名前を付けるために時間とエネルギーを費やしたいのはなぜですか?

たぶん、これはSOに関する別の質問に分岐する必要があります。

次のような関数ベースのビューがありました。

成功した場合はアカウントの詳細が表示され、アカウントにアクセスする権限がないか存在しない場合は 404 が表示されます。

私はクラスベースのビュー（DetailViewを拡張）を使用して同じものを実装しようとしていましたが、これを思いつきました：

urlconf:

この態度は機能しますが、2 つの余分なクエリが発生し、見た目が正しくありません。

同じ結果を達成するための標準的またはよりエレガントな方法はありますか?

クラスベースのビューに関するDjango1.3のドキュメントは、宝探しのようです。クラスの書き方は十分に明確です...しかし、どのような種類のテンプレートコードが各ジェネリッククラスに一致しますか？誰かがナッツに完全な例のスープを提供しますか？これが私がこれまでに持っているものです：

urls.py

views.py

generic_form_popup.html

この場合、古いスタイルがまだ機能していることを考えると、新しいスタイルを学ぶ価値があるかどうかを調べています。

urls.py

views.py

generic_form_popup.html

Django プロジェクト用のカスタム クラス ベースのビューを作成していますが、属性に関する設計上の決定に直面しました。

ゲッター関数

Django のジェネリック ビューを調べたところ、クラス変数とカスタム ゲッター関数の両方を提供するクラスが非常に多くあることがわかりました。例えば。

この設計上の決定は理にかなっています。そのようにするsuper()と、拡張クラスのオーバーライド メソッドを呼び出すことができるからです。

プロパティ

私のプロジェクトでは、単純な値を使用してオーバーライドできる特定の値がありますが、動的に生成する必要がある場合があります。最初は上記と同様のメソッドを作成しましたが、これを行うにはプロパティの方が適しているのではないかと考えました。

インスタンス.__dict__

これらの値をテンプレート内で使用する予定です。拡張ビューのインスタンスをテンプレートに渡し、次の方法で属性を表示します。

これはテンプレートであり、インスタンス属性が値であるか関数であるかは問題ではないため、次のようにクラスを記述することもできます。

def counterは、 の古い値ベースの属性を置き換えますinstance.__dict__。

質問

質問にたどり着くには、リストされているアプローチのどれが最良の選択ですか?

• super()親のゲッター関数を呼び出すことができるので、ゲッターのアプローチは素晴らしいですが、ほとんどの場合、それはおそらく必要ありません。
• プロパティ アプローチははるかに単純であり、記述されるコードが少なくなります。super()ただし、親のプロパティ関数を呼び出すことはできません。ほとんどの場合、この動作は必要ありませんが、super()機能が必要な場合があるため、プロパティとカスタム getter 関数を使用してオーバーライドできる単純な属性が混在しています。
• 最後のアプローチは、プロパティ アプローチよりもさらに少ないコードですが、スタイルが良いとは思えません。

Django のクラスベースの UpdateView では、ユーザー フィールドはシステムの内部にあるため除外し、要求しません。ユーザーをフォームに渡す適切なDjangoの方法は何ですか。（私が今それを行う方法は、ユーザーをフォームのinitに渡し、フォームのsave（）メソッドをオーバーライドすることです。しかし、これを行う適切な方法があると確信しています。隠しフィールドまたはそのようなもの自然。

クラスベースのビューに切り替えています。また、JavaScript を使用して、クライアント側で削除を確認します。Django DeleteView には、気にしない削除確認テンプレートが必要です。

Djangoであらゆる種類の削除の確認を無効にする簡単な方法はありますか?

1.3 からの Django の新しいクラスベースのビューについて頭を捻ろうとしています。

私は少し読んだ：

• http://reinout.vanrees.org/weblog/2011/08/24/class-based-views-usage.html
• http://www.caktusgroup.com/blog/2011/12/29/class-based-views-django-13/

しかし、私が見たことのない例や方法は、いくつかのビューが共通の「親」クラスをサブクラス化して、そこからデータを再利用できるかどうかです。（一般的な命名法のスラッシングを許してください）

私がやろうとしていることの例:

したがって、2 つの子クラスの違いは、使用するテンプレートと返される「データ」だけです。どちらのビューも、親クラスから session_data と other_variables を返すため、すべての子クラスで「return session_data, other_variables」を繰り返すことはありません。

こんにちは、django.utils.decorators method_decorator デコレータを理解しようとしています。method_decorator は、関数デコレーターをクラス メソッド デコレーターに変えます。

このデコレーターのソースは (https://github.com/django/django/blob/master/django/utils/decorators.py) にあります。

私の関数デコレーターの例:

私の基本クラスの例:

ここで、django.utils.decorators method_decorator を使用して Myclass メソッド undecorated_function を装飾する継承クラスを作成したいと考えています。method_decorator を機能させるには、継承されたクラスで関数を再定義する必要があります。

だからこれはうまくいきます：

私は少し混乱しており、以下のコードが機能せず、構文エラーが発生する理由がわかりません。

これは正しく解釈されず、構文エラーが発生します。

再定義せずに子クラスの関数を装飾するにはどうすればよいですか?

このブログ投稿に投稿されたミックスインのコードを理解しようとしています。

これらのミックスインは、ミックスイン内login_requiredからデコレータを呼び出しますが、 fromによって装飾されます。以下のサンプルコードでは、デコレータを装飾する必要がある理由がわかりません。django.contrib.auth.decoratorsmethod_decoratordjango.utils.decoratorslogin_required

デコレータは、method_decorator「関数デコレータをメソッドデコレータに変換する」ために使用されると言っていますが、テストコードでは、method_decoratorがなくてもデコレータを使用できます。

私のデコレータ

上記のデコレータを直接呼び出すクラスは、によって装飾されたデコレータを呼び出す場合と同じ結果を直接生成します。method_decorator