Соображения по упрощению разработки Ajax-приложений
Сейчас все чаще приходится разрабатывать приложения с Ajax. Да, приложения с применением этой технологии интерактивны и удобны. Но разработка усложняется. Причем, не столько за счет того, что нужно писать дополнительный код и изучать новый подход, сколько из-за добавления нового слоя приложения, сильно завязанного с другими, что исключает его создание и отладку в отрыве от остальных слоев. Приходится править сразу html, css, JavaScript и бек-энд скрипты (Perl, php, Ruby и сотоварищи). В этом посте хочу немного поразмышлять о том, как упростить себе жизнь.
Действительно, когда пишешь обычное приложение, то разработка идет своим чередом: верстка — это привычная связка html+CSS. Тут ничего сложного. При помощи этой связки создается шаблон, который затем оживляется с помощью серверного скриптования. Это — уже отдельный "поток" мышления, потому что когда мы пишем скрипт на php, мы думаем только о нем и не запариваемся над версткой (при правильном подходе к проектированию) и чем бы то ни было еще. Мы работаем с данными.
Но все меняется, когда приходят "они"! Если мы включаем в разработку Ajax, то приходится переключаться с html+JavaScript на php, иногда цепляя CSS. Приходится разрываться между четырьмя технологиями, которые не очень-то похожи! Лично у меня это вызывает дискомфорт, поэтому я решил немного поанализировать это дело и выработать некоторые рекомендации по разработке таких многоаспектных приложений.
Многоязычность вредит
Если мастер стоит за станком, то он не думает о станке, он думает о деле. Если мастеру нужно обслуживать несколько станков, бегая между ними, он начинает потеть и тяжело дышать. А если станки еще и разного типа, то он обязательно начнет сверлить на фрезе и, в конечном итоге, сунет руку под пресс. Поэтому первое, о чем необходимо подумать — уменьшение количества одновременно использующихся технологий. Например, CSS на начальных этапах разработки можно опустить (добавлять id и class можно уже в начале, но стили для них прописывать можно и потом). Это снизит нагрузку на внимание и кратковременную память и уменьшит количество открытых окон (мы ведь заботимся об оперативной памяти).
Разделяй и властвуй
Обычно, когда мне приходится делать сложную связку, я делаю ее максимально фрагментированно. То есть, сначала делаю максимально возможное количество полезной работы в одном месте, затем — в другом и т.д. Например, сначала я верстаю html. Для этого совсем не обязательно нужно сразу писать JS-обработчики. Конечно, потом придется их добавить, но это будет еще не скоро и применительно к почти готовому макету.
Еще вариант: при отладке Ajax-запросов, можно серверную часть сделать (временно) максимально простой. Скажем:
<?php
header(...)...;
print("Hello, world!");
?>
Да, мы не будем ловить запросы, да мы не будем делать выборки и анализировать что-то. Мы просто будем говорить, что серверная часть получила запрос. При написании функции обратного вызова, можно пока ограничиться чем-то в духе:
function calback(aj) {
alert(aj.responseText);
}
Эта заглушка будет выдавать только то, что запрос был отослан, вернулся и мы что-то там получили. На основную логику реакции на события, формирования запроса и т.п. это не влияет, но уменьшает взаимодействие между слоями. Потом, конечно, придется к этому вернуться, но это уже будет проще, потому что точно знаешь, что в других местах все работает, что уменьшает головную боль.
Использование библиотек и тулкитов
Можно существенно облегчить себе жизнь, если использовать уже готовые решения. Использование CSS-фреймворков, JS-тулкитов и шаблонных html-макетов может облегчить жизнь. Даже если они используются временно. Нарпимер я, для Ajax предпочитаю использовать легкий, мощный и быстрый jQuery. Он так же хорошо подходит для работы с DOM, что часто нужно. Кроме того, держу всегда под рукой пару шаблончиков, куда можно быстренько встроить написанный JS и проверить работоспособность. Это экономит время и позволяет не задумываться на какое-то время о какой-то части разработки.
Проблемы серверной обработки Ajax.
Есть еще важная проблема, о которой стоит помнить. Часто бывает, что один и тот же скрипт обслуживает несколько аяксовых запросов. Это означает, что в этом скрипте должен стоять какой-то контроллер, обрабатывающий параметры и, в зависимости от параметров, по-разному обрабатывающий данные. Если этот контроллер включен в состав контроллера для обработки обычных запросов, то нужно иметь четкое представление о том, как сделать так, чтобы безболезенно отдать только то, что нужно и не более. Ведь при формировании ответа на обычные запросы мы формируем страницу, а при ответе на Ajax-запрос — только данные. Нужно выработать подход, при котором одно не будет путаться с другим. Решением может стать отдельный файл, содержащий контроллер и обработчики только для ajax-запросов. Это позволит не задумываться над совмещением разных типов вывода (например, шаблонизатор и print).
Много файлов - много проблем
Не стоит сразу выносить JS в отдельный файл. Это приведет к тому, что вы будете постоянно переключаться от окна к окну. Если делать это часто и в течение 5 минут, то закружится голова:) Лучше написать и отладить JS прямо в шаблоне, а потом уже вынести результат в отдельный файл. Хотя, иногда, стоит и оставить на месте — грузиться будет быстрее.
Ну, это только соображения. Возможно, я что-то не по уму делаю?
![[Valid RSS]](/img/valid-rss-rogers.png)
by SHAman