URL でビューを使用するこれら 2 つの異なる構文と混同しています。一般的なビューでは、これを使用します
views.myview.as_view()
しかし、ビューに独自のカスタム関数を使用する必要がある場合は、使用する必要があります
views.myview().myfunction
なぜ両者に違いがあるのか
なぜ機能しないviews.myview.myfunction
のですか
ビューは、クラスまたは関数として記述できます。コードの再利用について心配していなければ、おそらく関数の方が簡単です。ビューを書くためのドキュメントを見てください。次に、クラスベースのビューのドキュメントをざっと見てください。最後に、URL ディスパッチャーのドキュメントを確認してください。
ビュー関数は次のように記述されます-
def my_view(request, *args, **kwargs):
...
return HttpResponse()
ビュー関数は、次のように関数を urlpatterns に渡すことによって呼び出されます -
from django.conf.urls import patterns
from views import my_view
urlpatterns = patterns('',
(r'^my_page/$', my_view)
)
クラス ベースのビューを使用すると、継承を通じて機能を再利用できます。
from django.views.generic import DetailView
class MySpecialDetailView(DetailView):
...
# add functionality here
問題は、URL セットアップがクラスではなく関数を想定していることです。そこでas_view()
関数の出番です。クラスベースのビューは、url conf で次のように呼び出されます。
from django.conf.urls import patterns
from views import MySpecialDetailView
urlpatterns = patterns('',
(r'^my_special_page/$', MySpecialDetailView.as_view())
)
私があなたの質問を誤解した場合はお詫び申し上げます
クラス メソッドは、クラスas_view()
の新しいインスタンスを作成し、View
そのdispatch
メソッドに制御を渡すビュー関数を作成します。したがって、各リクエストを処理するために使用されるビューの異なるインスタンスが作成されます。
2 番目の例では、ビューのインスタンスを 1 つだけ作成し、バインドされたメソッドをビュー関数として使用しています。これは、すべてのリクエストを処理するために同じインスタンスが使用されることを意味します (これは、2 つのリクエストによって同時に使用される可能性があることも意味します。この共有状態は、urlconf を読まない人には明らかではないため、バグが発生する可能性があります。
別のメソッドにディスパッチする必要があるだけの場合は、オーバーライドすることを検討してdispatch
ください。さまざまな場所でビューとは異なる動作が必要な場合はas_view
、インスタンス属性として使用できるキーワード引数を渡すことができます。dispatch
異なるリクエスト間で何らかの状態を共有する必要がある場合は、ビュー クラスの共有インスタンスで属性よりも明示的なものを使用することを検討してください。