Кто должен форматировать мои данные для отображения?

Question

У меня есть представление django, и это представление возвращает таблицу, которая асинхронно заполняется вызовом ajax.

С точки зрения дизайна, за чем мне следует следовать:

1. представление django, вызываемое через ajax, возвращает содержимое таблицы в виде ответа json, содержащего html-разметки для каждой ячейки. Обработчик обратного вызова javascript берет содержимое и помещает его без изменений в ячейки таблицы.
2. представление django, вызываемое через ajax, возвращает чистые данные о том, что должно попасть в таблицу, снова в виде ответа json. Асинхронный обратный вызов JavaScript принимает данные, форматирует их с правильной разметкой и помещает их в таблицу.

Другими словами, кто должен нести ответственность за форматирование разметки содержимого ячейки? представление или JavaScript?

Я бы хотел сказать первое, так как представление уже возвращает размеченное содержимое. Если он возвращает json, содержащий размеченный контент, то особой разницы нет.

Мне бы хотелось услышать вашу точку зрения.

Answer 1

Если вы заполняете всю таблицу, вы можете поместить ее в собственный шаблон и вернуть html таблицы через ajax / json.

Вам необходимо отредактировать исходный шаблон, чтобы включить шаблон таблицы:

 {% include "myapp/_table.html" %}

И в представлении верните представленный шаблон как переменную json, в которую ваш javascript подставит:

 return { 'table': render_to_string("myapp/_table.html", context) }

Этот подход хорош, когда вы всегда хотите обновить всю таблицу, а для рендеринга таблицы не требуется полный контекст. Я не уверен, на что похожа производительность, но это чистый способ обновления части страницы, потому что вы определяете свою таблицу только один раз.

Answer 2

Зависит (как часто).

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

Однако, если вы могли бы подумать о случаях использования, когда данные понадобятся в других местах (например, в полях с автозаполнением), было бы лучше позволить JavaScript выполнить эту работу и создать чистый, многократно используемый экспорт JSON.

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

Answer 3

Я сталкивался с этим несколько раз раньше и обычно выбираю последнее, где представление возвращает чистый JSON.

Однако выбранный вами подход должен определенно зависеть от нескольких факторов, одним из которых являются целевые устройства (и их ограничения ЦП / сети). Чистый JSON обычно приводит к уменьшению полезной нагрузки и поэтому может быть оптимальным для мобильных устройств.

Может также иметь смысл выставлять как HTML, так и JSON-версии вашего контента. Это особенно полезно, если вы хотите создать очень легкий API в какой-то момент для своего сайта.

Наконец, вы можете использовать библиотеку, такую ​​как микро-шаблонов *1007* или шаблонов закрытия Джона Ресига , для упрощения генерации HTML на стороне клиента.

Answer 4

Полезно практиковать Unabstrusive javascript, также называемый некоторыми людьми как Hijax

Итак, у вас сначала есть стандартная страница, которая представляет таблицу вместе с остальнымистраница, с таблицей в определенном блоке django-шаблона.

Когда у вас есть это, вы можете включить часть extends шаблона django в «если не ajax», так что вы получите только необходимую часть таблицы вответ ajax, который вы можете загрузить в клиенте на требуемый div.

Нет необходимости и избыточно поддерживать разметку дважды, один раз на сервере и один раз на клиенте, в javascript.

следовательно, я бы предпочел первый вариант - рендеринг сервера, а клиент загружал только визуализированный html.

Answer 5

В системе MVP , такой как Django, представление решает, какие данные должны отображаться, а докладчик решает, как они должны отображаться. Поэтому JavaScript должен выполнять основную часть форматирования, если только это не будет трудно сделать.

Answer 6

Я бы выбрал первый вариант, так как он предоставляет больше плюсов для пользователя: страница загружается мгновенно (без ожидания асинхронного вызова), JS не требуется (например, для мобильного устройства)