Стили Ajax

 

1. Создание готового HTML на сервере с автоматическим внедрением его в нужное место страницы;
2. Передача на страницу только структурированных данных и изменение по ним HTML’а скриптом на клиенте.

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

Что бы не кормить одной только теорией, попытаемся разобраться немного подробнее ою этих самых подходах к Ajax.

Передача HTML

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

К несомненным плюсам этого подхода относится исключительная простота идеи, из которой прямо вытекает, что на клиентской стороне можно автоматизировать практически все:

1. Подмена обычной кнопки в формы обработчиком на языке javascript;
2. Формирование этим самым обработчиком формы в вид, пригодный для отправки на сервер (name1=value1&name2=value2). Либо методом GET, либо POST;
3. Получение ответа от сервера вывод его в страницу пользователя.

Фактически все, что остается сделать программисту это:

1. Ткнуть пальцем в то, по какой кнопке он хочет "сделать ajax", и в какой блок на странице потом записать результат;
2. «Объяснить» серверу, какую именно часть информации необходимо вывести обратно в браузер пользователя при ajax запросе.

К минусам подхода я бы отнес то, что он существенно хуже работает для "высокодинамических" страниц, где от одного действия меняются разные части. Например длинный тред комментариев, где по сабмиту формы с текстом с сервера должен прийти новый комментарий и, скажем, обновиться строчка "N комментариев", которая находится в совсем другом месте страницы. Здесь, если следовать автоматической модели, надо передавать на страницу ту ее часть, которая включает все нужные куски, даже если между ними есть данные, которые и не предполагались меняться. На практике это может привести к тому, что по сети гоняются немаленькие объемы данных, сравнимые с размером собственно страницы, и весь смысл ajax’а вырождается в отсутствие эффекта анимации иконки браузера в правом верхнем углу.

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

Передача структурных данных

Передача структурированных данных была сутью ajax’а еще когда он назывался "XmlHttpRequest". То есть он был придуман для того, чтобы обратиться на сервер и получить описание какой-то части состояния системы, выраженной в XML — языке, который предназначен для удобной машинной обработки. Сразу скажу, что несмотря на то, что так было задумано, свет клином именно на XML-ответах не сошелся, и структуру можно передавать и по-другому, о чем чуть позже.

Плюс такого подхода — в максимальной гибкости. Можно придумать абсолютно любой формат и набор данных, который запрашивается у сервера, в котором будет в точности та информация, которой не хватает на клиенте, и ничего лишнего. На клиенте же с помощью Javascript’а можно изменить страницу полностью и как угодно.

Взять тот же пример с комментариями: на сервер отправляется комментарий, а в ответ возвращается например такое:

<comment status="ok" quantity="12"/>

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

Самый очевидный минус в передаче структуры — это гораздо больший объем и сложность программирования. Причем складывается она из нескольких вещей.

Первая сложность — это использование XML’а. Несмотря на то, что формат четкий и замечательный, в Javascript’е с ним можно работать только с помощью методов DOM. А это муторно писать и очень сложно читать: слишком много текста для производства простых вещей. К счастью, этот конкретный недостаток в последнее время решился с помощью формата JSON: данные возвращаются с сервера не в виде XML, а в виде куска Javascript’ового кода создающего объект нужной вам структуры:

response = {

status: 'ok',

quantity: 12

}

Он тут же в скрипте выполняется eval’ом и вы получаете объект response, у которого есть response.status и response.quantity. Очень удобно и без всяких

getElementsByTagName('response')[0].

Кроме избегания сложности разбора XML-ответа, остается второй момент: построение вручную DOM-методам самого HTML, что так же затруднительно и не очень хочеться.

Но самое плохое, что этим самым в системе появляются два совершенно разных места, в которых задается вид страницы: HTML-шаблон и Javascript’овый код. А значит изменения придется аккуратно дублировать и там, и там. И еще это значит, что для написания HTML’а вам теперь нужен человек, который умеет писать и HTML, и тяжелый Javascript. "Maintenance hell", иными словами.

Вообще, когда я начинал играться с XmlHttpRequest’ом, такой подход казался мне самым естественным: раз штука умеет парсить XML, значит это и есть правильный путь ее использования. Результатом тех упражнений стал довольно прикольный клиентский ajax-интерфейс к чату с множеством всяких фенечек. Тогда, в 2003 году, он был жутко передовым технологически, но раскрутить его во что-то известное мы так и не сподобились. Я даже удивился сейчас, что он до сих пор работает. Пусть теперь тут ссылочка для истории лежит :-)

Объединение лучших черт

Та несовместимость, о которой говорит Фрэнк Соммерс, присутствует только с точки зрения программиста, который выбирает передачу HTML, и не хочет погружаться в скриптование вообще. Однако если программист не против этого принципиально, то передачу структуры вполне можно объединить с передачей HTML’а. Принцип, на самом деле, очень простой:

1. Ответ с сервера отправляется в браузер пользователя в виде JSON-объекта;
2. Вещи, не связанные с генерацией HTML, выполняются скриптом, используя для этого данные из объекта (подвинуть элемент на странице, скрыть его или наоборот - открыть для пользвателя);
3. Если нунеобходимо менять какие-либо нетривиальные куски самого HTML, то они отправляются строками в том же самом объекте и вставляются в необходимое место на странице;
4. Изменяемые части HTML в срипте на сервере формируются как небольшие «шаблоны», используемые при начальном формировании страницы, и в ajax-ответах.

Проще говоря, вся эта "великая идея" заключается в следующем: можно семло отказаться от пропагандируемой догмы, что необходимо "пользоваться только XML’ом" и использовать в скриптах то, что необходимо и будет удобно в данном случае.

Удачи в освоении Ajax и успехов в программировании...