2016-07-14 4 views
0

私はさまざまな企業の人々が使用するDjangoアプリケーションを開発しています。一部の企業では高度にカスタマイズされたビューが必要です。つまり、必要に応じてデフォルトのテンプレートを変更します。また、余分なコンテキスト変数が必要になることもあります。Django:カスタマイズされたビュー関数を返す

私の考えは、必要に応じて別々のビュー関数を作成することです。なぜなら、それを1つのビュー関数に入れようとすると非常に手早くなるからです。たとえば、のは、私はダッシュボード・ビューを持っているとしましょう:

def dashboard(request): 
    var1 = some_func() 
    context = {'var1': var1 } 
    return render(request, 'normal_template.html', context) 

は現在、同社のxは、カスタム・ダッシュボードを望んでいる:X社から、ユーザーが特定のページに移動するとき

def dashboard_for_company_x(request): 
    var1, var2 = some_func_x() 
    context = {'var1': var1, 'var2': var2 } 
    return render(request, 'template_for_x.html', context) 

だから、dashboard_for_company_xを使用する必要があります。他のすべてのユーザーは、元のダッシュボード機能を使用する必要があります。

私が考えることができる2つのオプションは次のとおりです。 1. urlに会社の名前を追加すると、URLリゾルバは正しいビュー機能を使用します。 2.ミドルウェアを使用して要求をインターセプトし、必要に応じて適切なビュー機能にリダイレクトします。

1はより良い選択肢のようですが、実際にはオプションではないので、会社名を含むテンプレートのすべてのURLタグを変更することを意味します。私は2はうまくいくと思うが、ちょっとハックのようだ。

2番を使用しても問題ありませんか、それとも良いオプションがありますか?

ビューのほんの一部だけがカスタマイズを必要とすることに注意してください。

答えて

1

あなたのビュー関数の内部でルーティングを行うことができ、例えば:

def dashboard(request): 
    if request.user.company == 'foo': 
     return dashboard_foo(request) 
    elif request.user.company == 'bar': 
     return dashboard_bar(request) 
    else: 
     return dashboard_standard(request) 

ビューの複雑さに応じて、それはclass based viewを使用しても意味がありますので、あなただけの(固有のロジックを交換する必要がありますテンプレート、コンテキスト変数など)をすべてのユーザで同じにする(つまり、コードの重複を減らす)ことができます。

関連する問題