Создание HTML: PHP на стороне сервера или на стороне клиента jQuery - PullRequest
38 голосов
/ 22 февраля 2010

Это вопрос дизайна. У меня есть данные, которые нужно поместить в таблицу HTML, которой впоследствии будет манипулировать пользователь. В основном пользователь сможет выбирать элементы в строках таблицы.

У меня есть два варианта - в обоих случаях я использую AJAX для получения данных:

  1. Создайте HTML-код, используя PHP на стороне сервера, отправьте его клиенту в виде HTML. Затем пользователь манипулирует таблицей, используя Javascript (по сути, jQuery).

  2. Отправьте необработанные данные клиенту с помощью JSON, затем используйте jQuery для создания HTML-кода и последующей манипулирования им пользователем.

Какой подход рекомендуется с точки зрения дизайна / простоты кодирования / красоты? Спасибо за понимание.

Ответы [ 6 ]

36 голосов
/ 22 февраля 2010

Зачем генерировать HTML в PHP:

  • JavaScript должен определять поведение, а не содержимое.
  • Создание в JavaScript требует больше разметки (многострочные строки не так просты, как в PHP).
  • Сложнее поддерживать, если ваш HTML генерируется в нескольких местах (PHP & JS).
  • Вы можете использовать функции манипулирования DOM в jQuery для создания своего HTML, но в долгосрочной перспективе вы стреляете себе в ногу.
  • Создавать HTML на сервере быстрее, чем в браузере (в вычислительном смысле).
  • Зацикливание легче с PHP & ndash; легко создать разметку таблицы.
  • Вы сохраняете некоторую совместимость, если у пользователя отключен JavaScript, если вы выводите разметку при загрузке страницы.

Зачем генерировать HTML в jQuery:

  • Вы бы сэкономили немного пропускной способности.
  • Связывание событий может быть проще.

Итак, я за первый вариант, генерирующий HTML в PHP.


Визуальное сравнение двух методов, создание простой таблицы.

Вариант 1 с использованием PHP:

// PHP

$html = '<table>';    
foreach($data as $row) {
    $html .= '<tr>';
    $html .= '<td><a href="#" class="button">Click!</a></td>';
    $html .= '<td>'.$row['id'].'</td>';
    $html .= '<td>'.$row['name'].'</td>';
    $html .= '</tr>';
}
$html .= '</table>'; 
echo $html;
?>

// jQuery

$('#container').load('handler.php', function() {
    $('#container a.button').click(function() {
        // Do something
    });
});

Вариант 2, используя jQuery:

// PHP

echo json_encode($data);

// jQuery

$.ajax({
    url: 'handler.php',
    dataType: 'json',
    success: function(data) {
        var table = $('<table />');

        var len = data.length;
        for(var i = 0; i < len; i++) {
            var row = $('<tr />');
            var a = $('<a />').attr('href', '#').addClass('button');

            row.append($('<td />').append(a));
            row.append($('<td />').html(data[i].id);
            row.append($('<td />').html(data[i].name);

            table.append(row);
        }

        table.find('.button').click(function() {
            // Do something
        });

        $('#container').html(table);
    }
});

С точки зрения дизайна / простоты кодирования / красоты, я бы определенно сказал: подход с PHP.

4 голосов
/ 16 ноября 2011

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

2 голосов
/ 22 февраля 2010

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

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

Однако, если вы создаете новые узлы путем создания строки HTML, вам необходимо использовать кодировку HTML, чтобы обеспечить правильное экранирование любых <, & или кавычек. Там нет встроенной функции, чтобы сделать это в JavaScript, как htmlspecialchars в PHP; написать его довольно просто, но, кажется, никто не беспокоится. Результатом являются приложения jQuery, которые заполнены дырами в безопасности межсайтовых сценариев на стороне клиента, так же, как мы начинали добиваться некоторого прогресса в исправлении серверной части XSS.

1 голос
/ 22 февраля 2010

Мне очень нравится идея объединить подобные вещи на стороне клиента. Я нашел JavaScriptMVC хорошей платформой (версия 2.0 основана на jQuery) для этого, потому что она имеет шаблоны вида на стороне клиента (хотя не всем нравится такой подход).

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

1 голос
/ 22 февраля 2010

Не менее убедительные аргументы могут быть выдвинуты для обоих, но вы, скорее всего, будете отправлять меньше данных по конвейеру, если перейдете с 2.

0 голосов
/ 22 февраля 2010

Обе опции имеют плюсы и минусы, однако andras дает хорошее представление о том, должен ли контент быть проиндексирован / доступен для поиска. Лично я бы выбрал вариант 1, хотя и считаю, что архитектуру будет проще создать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...