Почему это - плохая практика для возврата сгенерированного HTML вместо JSON? Или это?
https://docs.python.org/2/library/subprocess.html
... или для очень простой команды:
import os
os.system('cat testfile')
8 ответов
- Сколько времени у вас уйдет на разработку новой системы, которая будет отправлять данные в виде JSON + кода JS, необходимого для внедрения их в виде HTML на страницу?
- Сколько времени потребуется, чтобы просто вернуть HTML? И как долго, если вы можете повторно использовать часть вашего уже существующего серверного кода?
И чтобы ответить на другой ответ: если вам нужно обновить более одной части страницы, все еще существует решение / хак отправки все эти части внутри одной большой строки, которая группирует несколько частей HTML и извлекает соответствующие части в JS.
Например, вы можете вернуть некоторую строку, которая выглядит следующим образом:
<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->
Это выглядит не очень хорошо, но это определенно полезно (я использовал его довольно много раз, в основном, когда данные HTML были слишком большими для инкапсуляции в JSON) :
Отправка json обычно выполняется, когда у вас есть виджет javascript, запрашивающий информацию с сервера, такую как список, древовидное представление или автозаполнение. Это когда я отправляю JSON, поскольку это данные, которые будут анализироваться и использоваться в сыром виде. Однако, если вы просто собираетесь показывать HTML, тогда гораздо меньше работы по его созданию на стороне сервера и просто отображению его в браузере. Браузеры оптимизированы для вставки HTML непосредственно в dom с помощью innerHTML = "", поэтому вы не ошибетесь с этим.
В зависимости от вашего пользовательского интерфейса вам может потребоваться обновить два (или более) разных элемента в вашей модели DOM. Если ваш ответ в формате HTML, собираетесь ли вы проанализировать его, чтобы выяснить, что куда? Или вы можете просто использовать хеш JSON.
Вы даже можете объединить его, вернуть JSON с данными HTML :)
{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }
IMV, все дело в отделении данных от представление данных, но я использую Паскаль, из этого не обязательно следует, что это разделение может происходить только на границе клиент / сервер. Если у вас уже есть это разделение (на сервере) и вы просто хотите что-то показать клиенту, то отправляете ли вы обратно JSON и обрабатываете его на клиенте, или просто отправляете обратно HTML, полностью зависит от ваших потребностей. Сказать, что ты "неправ"
Если ответ не требует дальнейшей обработки на стороне клиента, я считаю, что HTML подходит. Отправка JSON только заставит вас выполнить эту обработку на стороне клиента.
С другой стороны, я использую JSON, когда не хочу использовать все данные ответа сразу. Например, у меня есть серия из трех связанных выборок, где выбранное значение одного определяет, какие значения будут использоваться для заполнения второго и т. Д.
В основном я согласен с высказанными здесь мнениями. Я просто хотел резюмировать их следующим образом:
Это плохая практика - отправлять HTML, если вы в конечном итоге разбираете его на стороне клиента, чтобы провести над ним некоторые вычисления.
Это плохая практика - отправлять JSON, если все закончится это сделать, чтобы включить его в дерево DOM страницы.
JSON - очень универсальный и легкий формат. Я обнаружил его красоту, когда начал использовать его в качестве данных парсера шаблонов на стороне клиента. Позвольте мне объяснить, хотя раньше я использовал smarty и view на стороне сервера (создавая высокую нагрузку на сервер), теперь я использую некоторые пользовательские функции jquery, и все данные отображаются на стороне клиента, используя браузер клиентов в качестве анализатора шаблонов. это экономит ресурсы сервера, а с другой стороны, браузеры ежедневно улучшают свои JS-движки. Таким образом, скорость анализа клиента сейчас не является важной проблемой, даже более того, объекты JSON обычно очень малы, поэтому они не потребляют много ресурсов на стороне клиента. Я предпочитаю иметь медленный сайт для некоторых пользователей с медленным браузером, а не медленный сайт для всех из-за очень загруженного сервера.
С другой стороны,
Я думаю, это зависит от структуры дизайна, просто использовать JSON привлекательнее, чем HTML, но вопрос в том, как с этим справиться, чтобы его было легко поддерживать.
Например, у меня есть страница со списком, которая использует тот же HTML / стиль, что и весь сайт, я бы написал глобальную функцию для форматирования этих частей HTML, и все, что мне нужно сделать, это передать объект JSON в функцию .