Что должно генерировать HTML: JavaScript или php? - PullRequest
15 голосов
/ 18 декабря 2009

Быстрый вопрос, ищу некоторые рекомендации. У меня есть сайт, который будет запрашивать данные из базы данных и отображать их пользователю в таблице. Я использую JQuery (AJAX), PHP и MySQL.

Где лучшее место для генерации HTML-кода для таблицы для отображения данных: должен ли php сгенерировать его и отправить все (HTML + данные) обратно с сервера, или php просто отправит обратно данные, а код jQuery составляют таблицу и вставляют данные?

Хотя это выполняется в интрасети, я все равно предпочел бы самый быстрый подход.

UPDATE:

Я хотел бы добавить немного дополнительной информации в эту тему на случай, если она будет полезна другим. Я полностью согласился с идеей разделения, представленной здесь, и принял это как мой подход к проектированию. Я использовал PHP для извлечения и организации необходимых данных в JSON, а затем использовал jQuery для генерации HTML-кода для отображения возвращаемой информации. В этом случае я создавал форму таблицы стилей электронной таблицы, используя jQuery, и заполнял «ячейки», значения которых были возвращены из PHP. С несколькими строками и столбцами все работало нормально, но, как я уже сказал, таблица 16 x 16, динамически создающая элементы ввода с помощью jQuery ...

В этот момент я снова столкнулся с ужасным призраком IE6.

IE6 по-прежнему является одобренным браузером, в котором я работаю, поэтому мое приложение должно работать на нем. Когда я тестирую свой дизайн в Firefox и Opera, интерфейс загружается быстро и его приятно использовать. Когда я запускаю тот же код в IE6, генерация интерфейса занимает слишком много времени; достаточно долго, чтобы мои пользователи снова начали щелкать, думая, что приложение не отвечает. Я могу записать это только на движок JavaScript, который есть в IE6, так как код отлично работает в новых браузерах. Поэтому я вернулся к редизайну части интерфейса, чтобы PHP генерировал хотя бы элементы внутренней таблицы, заполнял данными, а затем отправлял их обратно клиенту. Это нарушает то хорошее разделение, которое я хотел, но я не вижу другого способа ускорить процесс на стороне клиента в IE6.

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

Ответы [ 8 ]

7 голосов
/ 18 декабря 2009

Хорошей стратегией является использование подхода "разделения интересов" , то есть Client Side для придания привлекательности аспектам GUI.

Также обратите внимание, что эта стратегия хорошо согласуется с текущими тенденциями в Интернете, например. Google Web Toolkit (GWT).

4 голосов
/ 18 декабря 2009

Пропускная способность интрасети не является узким местом, старый неуклюжий механизм IE JS может быть, поэтому я бы сказал, отправлять сгенерированный HTML (даже в лучших браузерах собственный разбор HTML-фрагментов должен выполняться быстрее, чем создание DOM с JS).

3 голосов
/ 18 декабря 2009

Большинство скажет, что AJAX должен быть чистыми данными, без разметки html. Я не согласен с этим, я считаю, что AJAX хорош в загрузке карманов HTML в местах на экране. Я думаю, с точки зрения кодирования, проще генерировать HTML-код с использованием технологии на стороне сервера, а затем позволить javascript просто отобразить его на той странице, куда он должен перейти. Он будет работать хорошо, он будет эффективным (innerHTML - самый эффективный способ размещения нового html на странице), и обслуживание кода будет проще. Если вы позволите javascript генерировать html, вам придется беспокоиться о двух местах, если что-то изменится с отображением, а не только с PHP.

1 голос
/ 18 декабря 2009

Если вы собираетесь использовать самый быстрый подход: отрендерируйте HTML-сервер с помощью PHP. Если вам нужен более понятный и понятный подход к коду: попросите PHP отправить JSON в код AJAX. Таким образом, вы можете поддерживать хорошее разделение данных от представления и поведения. Будет проще изменить внешний вид и работу вашего сайта, если вы сможете управлять рендерингом HTML в одном месте - на клиенте.

1 голос
/ 18 декабря 2009

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

Если пользователь собирается фильтровать / запрашивать несколько обновлений данных с сервера ... Я бы возвратил данные через PHP в формате JSON в Javascript и позволил бы Javascript отображать HTML на странице.

1 голос
/ 18 декабря 2009

Самым быстрым с точки зрения пропускной способности сети является вывод PHP в формате JSON и использование jQuery для создания разметки.

Самым быстрым в плане обработки на стороне клиента (и, возможно, реализации) является использование PHP для генерации разметки - например, с использованием шаблонов - и передачи ее через Ajax.

0 голосов
/ 18 декабря 2009

Я бы создал HTML на стороне сервера и использовал бы JavaScript, чтобы внести небольшие изменения в HTML. Вы не можете создать HTML-страницу, которая действительна для всех браузеров, и обнаружение ее со стороны сервера не гарантировано на 100%; Вы не можете доверять идентификатору агента пользователя, так как многие браузеры позволяют пользователю выбрать другой, и единственный способ создать HTML, специфичный для семейства браузеров, - это проверить, реализовано ли используемое свойство.

То, что я сообщаю, действительно в целом; в конкретном случае он не может быть действительным.

0 голосов
/ 18 декабря 2009

Одна вещь, которую я не видел в других ответах: консистенция: Когда кто-то видит отрендеренную страницу, он ожидает, что сможет сохранить эту страницу в виде статического HTML - (хотя в эти "дни 2.0 сети" сейчас все меньше), но при прочих равных условиях, пользователь должен иметь возможность сохранить то, что он видит, как статическую страницу: поэтому вы должны отправить его предварительно отрендеренным в html с сервера.

...