Подтвердить что ты не робот

Django - два вида, одна страница

Скажем, у нас есть страница Django, которая показывает список элементов и позволяет пользователю заполнить форму для добавления к элементам (позвольте вызывать сообщения о позициях).

Что я хочу: URL-адрес этой страницы относится к представлению. Представление вызывает два других вида (называемых здесь "под-представлением" ), затем каждый под-просмотр отображает его раздел и возвращает результаты. Затем основной вид объединяет результаты под-представлений и возвращает это.

В идеале, у меня быстрая проверка javascript на странице - если javascript включен, кнопка отправки формы будет "Ajax'd" для подзадачи, которая занимается добавлением формы, и страница будет обновлено таким образом. Я полагаю, что я мог бы вызвать запрос на обновление списка сообщений или слишком.

Итак, как мне объединить два под-представления в главном представлении? Возможно ли это?

UPDATE: "под-просмотр" - это термин, который я составил. То, что я хочу, - это представление, которое может быть вызвано Ajax непосредственно, чтобы вернуть что-то значимое или из другого представления (которое я назову "основной вид" ). Если вызвано этим "основным видом", как главный дескриптор представления возвращает данные из нескольких "под-представлений"?

Есть ли простой способ сделать это? Это подходящий способ подумать о нескольких взглядах на странице? Должен ли я заботиться о разделении обязанностей?

4b9b3361

ОТВЕТЫ

Ответ 1

Вид в django - это просто любое вызываемое, которое в конечном итоге возвращает объект Response. В этой точке зрения вы можете разделить работу на любую организацию, которая вам подходит. Возможно, ваш взгляд на 100% делегатов на другие методы.

В вашем случае ваше основное представление вызовет две другие функции для данных. Они также могут быть представлениями, если они также принимают объект Request и используют его. Им также нужно будет вернуть объекты Response, которые будут считаться представлениями django, поскольку именно так вы укажете URL-адреса на них. Но на самом деле вам нехорошо иметь два других вида, возвращающих вам объекты Response. То, что вы, вероятно, хотите, это просто другие методы, которые выполняют конкретные задачи и возвращают некоторую структуру данных или, возможно, даже рендеринг фрагмента шаблона. Затем вы должны использовать эти данные или объединить строки шаблонов вместе и вернуть их в свой основной ответ.

Если вы действительно настроены на использование других представлений, возвращающих объекты Response, то вы можете сделать что-то вроде захвата тела из них и слияния их в свой собственный ответ:
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

Ответ 2

Представления должны содержать только связанную с просмотром логику:

  • Представления предназначены для обработки запросов и обслуживания запрошенных данных.
  • Это включает проверку авторизации пользователя/разрешения и обработку заданных параметров
  • Если запрошенные данные не являются тривиальными для извлечения, передайте код в более подходящее место (ваши определения модели или формы или другое пользовательское место).

Расчеты аутсорсинга, чтобы сделать их многоразовыми и вызвать эти методы из ваших представлений, чтобы они были небольшими.

Тем не менее, возможно, вам нужно что-то еще, а именно шаблоны с extends и include.

С помощью extends вы можете создать базовый макет для своего HTML-кода и определить определенные блоки, которые можно отобразить в другом месте. Пример? Хорошо.

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>

Затем в любом другом шаблоне вы можете перезаписать блоки title и content, которые мы определили в базовом шаблоне:

{% extends "base.html" %}

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

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

Кроме того, вы можете создать подшаблоны, например, следующие, пусть назовите его _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 %}

Я надеюсь, что это поможет.

Ответ 3

Это идеальное время для представления видов, основанных на классах.

методы класса - это, по существу, "подчиненные представления", которые разделяют логику на фрагменты многократного использования.

Если вам нужна читаемость разделяемых функций, она становится лучше, если использовать классы на основе класса django (через все функциональные возможности, предоставляемые по умолчанию, и доступ к запросу, kwargs, args и т.д. через экземпляр класса).

Документы даже содержат хороший пример для возврата ответа JSON или ответа HTML на основе параметров запроса (эта точная ситуация).

Лучшая часть? Вы можете повторно использовать свои представления на основе класса как mixins в будущих представлениях. Посмотрите пример документа, чтобы увидеть, как преобразовать любой класс, основанный на представлении, для обработки ответа JSON контекста шаблона с помощью простого подкласса.