2012-05-15 16 views
26

Djangoのページにはアイテムのリストが表示され、ユーザーはアイテムに追加するフォームを記入できるとします(アイテムの投稿と呼ぶ)。Django - 2つのビュー、1つのページ

私が欲しいもの: このページのURLは、ビューを参照しています。ビューは2つの他のビュー(ここでは「サブビュー」と呼ばれる)を呼び出し、各サブビューはそのセクションをレンダリングし、結果を返します。メインビューは、サブビューの結果を結合し、それを返します。

理想的には、私はページ上で簡単にjavascriptをチェックします - もしjavascriptが有効になっていれば、フォームのサブミットボタンはフォーム追加を扱うサブビューに "Ajax'd"されます。そのように更新される。私は後で投稿のリストを更新するリクエストをトリガできると思う。

メインビューで2つのサブビューを連結するにはどうすればよいですか?これは可能ですか?

更新日:「サブビュー」は私が作った用語です。私が望むのは、Ajaxが直接意味のあるものを返すか、別のビュー(「メインビュー」と呼ぶ)から返すことができるビューです。この「メインビュー」によって呼び出された場合、メインビューは複数の「サブビュー」からデータを返す方法をどのように処理しますか?

これを行う簡単な方法はありますか?これはが適切なのですか?ページ内の複数のビューを考える方法はありますか?私は責任の分離を気にすべきですか?

+0

サブビューは独自の用語です。彼らは何を返すかによって決まります。 html?データ? – jdi

答えて

15

djangoのビューは、最終的にResponseオブジェクトを返す呼び出し可能なものです。その視点の中で、仕事をあなたに合った組織に分けることができます。あなたの意見を他の方法に100%委任するかもしれない。

あなたの場合、メインビューは2つの他の関数をデータとして呼び出します。また、Requestオブジェクトも受け入れ、それを利用すれば、これらのビューを表示することもできます。彼らはまた、あなたがそれらにURLを指す方法であるので、DjangoビューとみなされるようにResponseオブジェクトを返す必要があります。しかし、Responseオブジェクトを返す他の2つのビューを持つことは、本当にあなたには良いことではありません。おそらく、特定のタスクを実行し、いくつかのデータ構造、あるいはテンプレートのレンダリングされたスニペットを返す他のメソッドだけかもしれません。これらのデータを使用するか、テンプレート文字列をマージしてメインのレスポンスに返します。 、本当に
https://docs.djangoproject.com/en/1.4/ref/request-response/

:あなたは本当にレスポンスオブジェクトを返す他のビューを利用することで設定されている場合

は、その後、あなたはそれらのうちの体をつかんで、そしてあなた自身の応答にそれらをマージするような何かを行うことができますチュートリアルとはまったく異なるものはありません。データのための他のメソッドを呼び出すだけです。構成する場合は、データ処理ロジックをビュー機能から分離する必要があります。メインビューでは、これらのデータ処理関数を値と呼ぶことにします。また、「サブビュー」は、これらの個々のデータ関数を呼び出してレスポンスにラップする単純なビューに過ぎません。

疑似:

def mainView(request): 
    val = data1() 
    val2 = data2() 
    response = # val + va2 + other stuff 
    return response 

def subView1(request): 
    val = data1() 
    response = # val + stuff 
    return response 

def subView2(request): 
    val2 = data2() 
    response = # val2 + stuff 
    return response 

def data1(): 
    val = # get data 
    return val 

def data2(): 
    val2 = # get data 
    return val2 
+0

そうですね、私は別のものとマージするための応答を返すことができません...私は、次に、3つのビューメソッドと2つの作業馬のメソッドが必要です。いわゆる「サブビュー」の作業は、作業馬の方法で行われます。データの取得、保存、何でも。ビューのうちの2つはちょうどどちらかの作業馬に委任し、そのデータを応答として返します。他のビュー - 「メインビュー」は両方の仕事の馬を呼び出し、それを応答として返します。右? – bharal

+0

@bharal:そうです。私がちょうどそれを示したアップデートを見てください。ビューを非常に軽くし、データをフォーマットするだけです。次に、ロジックを必要に応じてすべてで使用されるより一般的な関数に置きます。 – jdi

+0

こんにちはjdi - 私はこの答えが好きですが、完全性のために、Yujiによって提供される答えは異なりますか?同じ?問題を解決する別の方法は? – bharal

12

ビューはビュー関連のロジックが含まれている必要があります。

  • ビューは、処理要求のためのものであり、ユーザー認証/許可のチェック含まれていることを
  • 要求されたデータを提供します指定されたパラメータを扱う場合
  • 要求されたデータが取れない場合は、コードをより適切な場所に委託する(お使いのモデルやフォーム定義または別のカスタムの場所)

アウトソーシングの計算は、それらを再利用可能にし、小さなそれらを保つために、あなたのビューからこれらのメソッドを呼び出します。

でも、多分あなたはextendsincludeのテンプレートが必要です。

extendsを使用すると、HTMLコードの基本レイアウトを作成し、他の場所でレンダリングできる特定のブロックを定義することができます。例? OK。あなたが作成することができます。また

{% extends "base.html" %} 

{% block title %}My Page{% endblock %} 

{% block content %} 
<h2>My Page</h2> 
<div>lorem ipsum</div> 
{% endblock %} 

、:

base.html:

<!doctype html> 
<html> 
    <head> 
     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> 
     <title>{% block title %}My Site{% endblock %}</title> 
    </head> 
    <body> 
     <div id="header"> 
      <h1>My Site</h1> 
     </div> 
     {% block content %}{% endblock %} 
    </body> 
</html> 

その後、他のテンプレートで、あなたは私たちが基本テンプレートで定義されたブロックtitlecontentを上書きすることができます次のようなサブテンプレート、_item.html

<li class="item"> 
    <span>{{ something.foo }}</span> 
    <strong>{{ something.bar }}</span> 
</li> 

あなたは、他のテンプレートでそのスニペットを含めるとパラメータの任意の数渡すことができます。

{% for something in mymodel.mym2mrelation.all %} 
    {% include "_item.html" with something=something only %} 
{% endfor %} 

当然、あなたは両方の概念を組み合わせることができます。ように:

{% extends "base.html" %} 

{% block title %}My Page{% endblock %} 

{% block content %} 
<h2>My Page</h2> 
<div>lorem ipsum</div> 
<ul> 
{% for something in mymodel.mym2mrelation.all %} 
    {% include "_item.html" with something=something only %} 
{% endfor %} 
</ul> 
{% endblock %} 

私は助けてくれることを望みます。

+0

ビューには、ビュー固有のロジックがすべて含まれている必要があります。ほとんどのビューコードは、ほとんどの場合、モデルに入れられないリクエストオブジェクトに依存します。あなたの投稿は新しいユーザーに混乱するかもしれません... –

+0

あなたは正しいです、私はそれを言い換えるでしょう – Alp

8

これは紹介する最適な時間ですclass based views.

クラスメソッドは、基本的に再利用可能なスニペットにロジックを分割する「サブビュー」です。

スプリット関数の読みやすさを望むなら、djangoのクラスベースのビュー(デフォルトで提供されているすべての機能と、request、kwargs、argsなどのクラスインスタンスを介してのアクセス)を使用するほうが上手くなります。

The docsにも、リクエストパラメータ(この厳密な状況)に基づいてJSON応答またはHTML応答を返す良い例が含まれています。

ベストパートですか?将来のビューでは、クラスベースのビューをミックスインとして再利用できます。 docsの例を見て、クラスベースのビューを単純なサブクラスを介してJSONレスポンスを処理する方法を変換する方法を見てください。

+0

これはjdi(哲学的には私が意味する)と同じ答えですか、それとも何か違うことを暗示していますか? – bharal

関連する問題