Который должен генерировать HTML: JavaScript или php?
Быстрый вопрос, ища некоторые рекомендации. У меня есть сайт, который будет запрашивать данные от базы данных и отображаться назад пользователю в таблице. Я использую jQuery (Ajax), php, и MySQL.
Где лучшее место для генерации HTML для таблицы для отображения данных: php должен генерировать его и отправить все это (HTML + данные) назад с сервера, или php должен просто передать данные обратно, и код jQuery делает таблицу и вставляет данные?
Хотя это работает на интранет, я все еще предпочел бы самый быстрый подход.
ОБНОВЛЕНИЕ:
Я хотел добавить немного дополнительной информации к этой теме в случае, если это могло бы быть полезно для других. Я согласился полностью с разделительной идеей, представленной здесь, и пошел с этим как мой подход дизайна. Я использовал PHP, чтобы получить и организовать необходимые данные в JSON, и затем использовал jQuery для генерации HTML для отображения возвращенной информации. В этом случае я создавал табличную форму стиля электронной таблицы с помощью jQuery, и заполняя "ячейки", которые имели значения, как возвращено из PHP. С несколькими строками и столбцами, хорошо работали вещи, но поскольку я увеличиваюсь для высказывания, таблица 16 x 16, динамично создавая входные элементы с jQuery...
На данном этапе я еще раз столкнулся с ужасным призраком, который является IE6.
IE6 является все еще утвержденным браузером, где я работаю, таким образом, мое приложение должно функционировать на нем. Когда я тестирую свой дизайн на Firefox и Opera, интерфейс загружается быстро и является удовольствием использовать. Когда я выполняю тот же код в IE6, он берет слишком долго для генерации интерфейса; достаточно долго то, что мои пользователи начинали бы нажимать вещи снова, думая, что приложение не отвечало. Я могу только рисовать мелом это до механизма JavaScript, который находится в IE6, так как код хорошо работает в более новых браузерах. Так, из-за этого я вернулся к модернизации для части интерфейса, чтобы иметь PHP, генерируют, по крайней мере, внутренние элементы табличной формы, заполняют с данными и затем передают это обратно клиенту. Это повреждает хорошее разделение, которое я хотел, но я не вижу никакой другой способ ускорить вещи на стороне клиента в IE6.
Так или иначе просто другие мысли могли бы интересоваться результатами здесь, и для других новичков как я, насколько требования поддержки браузера могут влиять на проектные решения.
8 ответов
Хорошая стратегия - использовать подход «разделения задач» , то есть использовать Клиентскую сторону , чтобы упростить аспекты GUI.
Также обратите внимание, что эта стратегия хорошо согласуется с текущими тенденциями в Интернете, например, с Google Web Toolkit (GWT).
Пропускная способность интрасети не является узким местом, может быть старый неуклюжий движок IE JS, поэтому я бы сказал, что отправка сгенерированного HTML-кода (даже в лучших браузерах нативный анализ HTML-фрагментов должен быть быстрее, чем создание DOM с JS).
Большинство считает, что AJAX должен быть чистыми данными, а не HTML-разметкой. Я не согласен с этим, я считаю, что AJAX хорошо загружает фрагменты HTML в места на экране. Я думаю, с точки зрения кодирования, проще сгенерировать HTML, используя технологию на стороне сервера, а затем позволить javascript просто разместить его на той странице, где он должен быть. Он будет работать хорошо, чем эффективнее (innerHTML - самый эффективный способ разместить новый html на странице), и обслуживание кода будет проще. Если вы позволите javascript генерировать html, тогда вам придется беспокоиться о двух местах, если что-то изменится с отображением, а не только о PHP.
Самый быстрый с точки зрения пропускной способности сети - это выход PHP в формате JSON и использование jQuery для создания разметки.
Самый быстрый с точки зрения обработки на стороне клиента (и, возможно, реализации) - использование PHP для создания разметки - например, с использованием шаблонов - и передачи ее через Ajax.
Одна вещь, которую я не видел в других ответах: консистенция: Когда кто-то видит визуализированную страницу, он ожидает, что сможет сохранить эту страницу как статический HTML - (хотя сейчас в эти "дни веб 2.0" это меньше), но все же, при прочих равных, пользователь должен иметь возможность сохранять то, что он видит, как статическую страницу: поэтому вы должны отправить его предварительно обработанным в HTML с сервера.
Я бы создал HTML на стороне сервера и использовал бы JavaScript, чтобы внести в HTML небольшие уточнения. Вы не можете создать HTML-страницу, которая действительна для всего браузера, и ее обнаружение со стороны сервера не является стопроцентным; вы не можете доверять идентификатору пользовательского агента, поскольку многие браузеры позволяют пользователю выбрать другой, и единственный способ создать HTML, специфичный для семейства браузеров, - это проверить, реализовано ли используемое свойство.
То, что я сообщаю, в целом справедливо; в конкретном случае он не может быть действительным.
Если вы можете получить данные и сгенерировать таблицу перед возвратом страницы пользователю, сделайте все это на PHP. На самом деле нет необходимости добавлять флэш-память AJAX, если вы ничего не получаете от этого.
Если пользователь собирается фильтровать / запрашивать несколько обновлений данных с сервера ... Я бы вернул данные через PHP в формате JSON в Javascript и позволить Javascript отобразить HTML на странице.
Если вы собираетесь использовать самый быстрый подход: рендеринг HTML на стороне сервера с помощью PHP. Если вам нужен более простой в обслуживании подход с чистым кодом: пусть PHP отправляет JSON в код AJAX. Таким образом, вы можете сохранить хорошее разделение данных от представления и поведения. Будет легче изменить внешний вид и работу вашего сайта, если вы сможете управлять отображением HTML из одного места - на клиенте.