Ajax

индекс
86,27

9 правил для начинающего Ajax-разработчика

Эти девять правил несложны, никаких кусков кода — только общие советы начинающим Ajax-разработчикам. Крайне вольный перевод 9 AJAX Tips & Tricks.


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

2. Используйте GZip
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных. В этом вам поможет эта страничка.

3. Планируйте разработку
Нельзя с кондачка написать серьёзное приложение. Больше планируйте, расчертите и продумайте всё что можно. Лучше, если вы это будете делать не в голове, а на бумаге, или в любом редакторе. Хорошее планирование спасает от огромного числа ошибок и от ненужной работы.

4. Пользуйтесь стандартами
Совершенно нет нужды изобретать велосипед. Используйте то, что дают вам стандарты в разработке Ajax-приложений. Среди них, к примеру, XML, HTML, XHTML, JSON, UED.

5. Проверяйте входящие данные
В этом плане вполне можно быть маньяком, не доверяя никому, кроме себя. Проверять необходимо моментально, благо скриптов моментальной проверки, к примеру, форм, сейчас море. Проверка на «месте» экономит время пользователя и ваше, как разработчика.

6. Проверяйте входящие данные и на сервере
Помните про маньяка? Вот и не доверяйте проверке на стороне клиента — в обязательном порядке проверьте и на стороне сервера. Не стесняйтесь указать пользователю, что он ошибся там и там.

7. Используйте SSL для приватной информации
Если вы оперируете с приватной информацией, то в обязательно порядке применяйте SSL — это позволит сохранить приватность и будущем не краснеть перед пользователями.

8. Фреймворки
Не изобретайте велосипед (хотя если вы только учитесь — изобретайте, это крайне полезно для развития вас — как специалиста) — до вас уже давным давно написали практически всё что можно. Используйте фреймворки для экономии времени разработки. Только без фанатизма.

9. Сначала базовый функционал
Во время разработки приложения (особенно если вы пишете его для себя), нередко возникают ситуации, когда на лету рождается идея для вашего приложения. Не торопитесь её реализовывать — аккуратно запишите её, и допишите то, что вы распланировали согласно пункту за номером 3. Позже, когда всё будет готово, соберите все идеи воедино, и снова распланируйте, как вы будете их внедрять.
+48
24 августа 2008, 16:54
93

комментарии (63)

+31
scr1pt #
В принципе, эти советы подходят ко всем аспектам web-разработки)
+3
absolvo #
Да, выкинуть пару советов (или сделать их более общими), и будут подходить почти ко всем аспектам )
+3
brook #
Вот и я также — ожидал что будут написаны советы в духе — используйте json вместо XML для передачи данных — а получил [b]типичные советы для начинающего веб-разработчика[/b].
–1
d_a #
В принципе эти советы подходят для любой разработки )
–5
Morfi #
Пункт 5 и 6 лишние, не какого отношения к Ajax.
+1
absolvo #
Почему? Мне кажется, что эти два пункта имеют самое непосредственное отношение к Ajax'у. Пусть и не всегда применимы, но тем не менее.
–2
Morfi #
Проверка данных относится к php (ну или кто на чем пишет) на сервере и javascript на клиенте, и то это только для юзабилити, где здесь Ajax?
–2
taliban #
Ajax = Asynchronous Javascript And XML… слово JavaScript в этой аббривеатуре присутствует
+4
artch #
Остальные тоже имеют слабую специфику для аякса. Обычные прописные истины. Американцы их любят.
0
HoochieMen #
Пункты 5 и 6 совершенно никогда не лишние ©
+4
dinamyte #
Фреймворки, естественно, ускоряют процесс разработки приложения, но зачастую просто необходимо разрабатывать не универсальные системы, а системы «точечные», узкоспециализированные, оптимизированные под конкретную ситуацию. Правда?
+4
absolvo #
Безусловно — если задача точечная — фреймворки только помешают.
0
taliban #
для каждой задачи можно подобрать свой фреймверк, не все они массивные, есть и маленькие наработки, по сути фреймверк — основа, а не готовый продукт
+2
qprst #
планирование — одно из самых важных правил
+2
absolvo #
Причём в любой области, будь то разработка приложения, или поход в кино с девушкой.
Согласен!
+1
komjah #
Главное не начать планировать как лучше все спланировать)) Как в том фильме.
+1
dug #
в каком, кстати, фильме?

Вообще первый этап проекта — планирование. Первая, скажем, фаза планирования — планирование планирования. Так в умных талмудах пишут, на деле, конечно, потом всё сводится к оперативному выходу из штопора, прямо начиная со второго этапа, но идея хорошая.
0
komjah #
Однажды в Вегасе, если не ошибаюсь.
0
raver #
неплохо было бы написать ссылочки еще к пару пунктам
+1
absolvo #
Всё что было на Вики — оформил в виде ссылок.
+1
raver #
+1
absolvo #
Спасибо!
Внёс в топик.
+1
raver #
+1
absolvo #
Да, ссылок там хватает. Дело в том, что по хорошему, надо бы дополнить эти ссылки ссылками на русскоязычные сайты, но время поджимало, так и забыл :(
–23
DarkV #
По-моему, в пункте 4, среди стандартов несколько пунктов лишние.
XML и XHTML например.
+2
absolvo #
Если XHTML и спорный вопрос, то XML отнюдь не лишний.
–6
Setti #
Наверно таки наоборот ;)
+6
croatian #
Насчет XML вы погорячились ;-)
0
DarkV #
absolvo, croatian:
Для аякса, не вижу его преимуществ перед JSON-ом.
+3
Angerslave #
Без XML AJAX уже не AJAX, а какой-нить AJAJ…
0
DarkV #
А, ну, да. Раз уж он так называется, нам ничего не остается, кроме как использовать XML…
0
Angerslave #
Думаю, скорее так исторически сложилось — передавать можно было хоть HTML для вставки сразу в элемент, но всеобщее XML-помешательство тогда было сильно:)
0
DarkV #
Вот и я о том же. Помешательство и сейчас еще есть, хоть и поменьше.
И XHTML из той же серии «давайте еще куда нибудь ввернем xml, это же так круто!».
0
Angerslave #
Хм, хоть это и из другой оперы, но для меня теги в стиле
это такой же анахронизм, как и … Поэтому из HTML и XHTML я выбираю последнее:)
0
DarkV #
Или я, или парсер чего-то недопоняли. =)
0
Angerslave #
Чёрт… теги в стиле <br>
0
gribunin #
XHTML нужен хотя бы для XSL преобразований, чтобы из XML получить веб-страницу.
–3
DarkV #
Ну это вынужденный XHTML. Не развалидировать же его!

XSL — инструмент для преобразования любого XML в любой XML. В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто». А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.

Вам не кажется, что в этой логике есть какой-то изъян? =)
+5
gribunin #
В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто».

Категорические утверждения редко бывают верными.

А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.

Мне, как разработчику, в принципе, всё равно какой именно протокол выбран IT сообществом стандартом (или одним из стандартов). Для меня имеет значение, что этот стандарт начинает поддерживаться в самых разных системах, что позволяет мне эффективно эти системы объединять в рамках одного проекта.

Например, используя XML я могу получить данные из хранимой процедуры в MS SQL 2005 в виде XML документа, затем применить к полученным данным XSL шаблон и получить XHTML документ, который посылается пользователю. В данном случае, производители БД, серверных библиотек и клиентского браузера поддержили один и тот же стандарт, что позволяет мне делать сложные вещи просто.

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

Разумеется, выбирая что-то в качестве стандарта для широго круга задач, невозможно выбрать что-то, что будет наиболее оптимальным для каждой конкретной задачи. Это может дать возможность говорить, что этот стандарт «плохой», а повсеместное использование стандарта называть «помешательством», как вы изволили написать выше, но я бы обратил внимание, что именно повсеместное использование и делает стандарт стандартом и позволяет единообразно работать с довольно разными системами.
+1
artch #
Ловите плюс в карму. Приятно читать грамотные комменты грамотного человека.
0
DarkV #
В вашем случае, конечно, против XMLа выступать глупо.

Но я же говорил не про ваш случай. Если в нем заменить MS SQL 2005 на «обычный порошок» то вся стройная картина, увы, рушится. Да и редко бывает, что бы результат запроса к БД можно было без дополнительно обработки отправлять в js.

Я же не предлагаю использовать JSON везде и всегда, я предлагаю думать головой (что конкретно вы, по-видимому, и делаете), а не использовать XML везде и всегда. И утверждаю, что для большинства задач, от использования XML нет ни какой пользы, акромя вреда.

Про «помешательство»: стандарт не бывает плохим. Но бывает, что он становится настолько раскрученным, что многие его начинают использовать не для упрощения, а наоборот. И как назвать поведение этих многих?
0
gribunin #
Про «помешательство» не вы писали, прошу прощения
+1
AmdY #
xslt трансформация на клиенте, явное преимущество
+16
Setti #
Куда важнее для ajax-разработчика знать, что
1) JS-ссылки должны работать и с выключенным JS.
2) Должна работать кнопка «Назад».
3) Полезный «ajax-контент» не должен быть скрытым для поисковиков.
4) Отображать индикацию процесса.
А то, что в топике — это не про ajax.
+1
AmdY #
ещё
5) кеширование в браузере
6) должна быть озможность востановления состояния по ссылке (очень удобно использовать location.hash)
7) используйте utf
8) обрабатывайте исключения, хотя это частично относится к индикации

последний) не злоупотребляйте ajax
–3
Antohins #
Чтобы мой бэкэнд скрипт не валили обычными пост запросами я в него втыкаю такой код:

if($_SERVER['HTTP_X_REQUESTED_WITH'] != 'XMLHttpRequest') die(«Ай нанэ нан»);

Ну это «защита» от ленивых хакеров. умный всегда найдет)
+10
TimTowdy #
Что за профессия такая, ajax-разработчик? Я понимаю web или javascript, но ajax… Это типа человек который не знает js, но знает как работает XmlHttpRequest?
Вот справа смотрю на вакансии вижу там PHP-программист, С Developer, python developer.
Почему-то никто не ищет stdio.h-разработчиков или UserString-разработчиков.
0
Angerslave #
AJAX включает в себя не только JavaScript, поэтому тонкости технологии XML, протокола HTTP и ещё разные другие вещи не менее важны, чем непосредственно знание JavaScript. Хотя AJAX-разработчик я тоже редко встречаю, чаще frontend-developer.
+1
TimTowdy #
XML нужно знать ровно настолько чтобы перестать использовать его без крайней на то необходимости (тот же JSON в большинстве случаев будет удобнее и быстрее). Если уж XML так необходим, то объяснить программисту, что это такое можно за несколько минут. В рамках использования его в ajax — это всего лишь еще один формат хранения данных, не более.
Тонкости HTTP? Большинство сегодняшних «ajax-разработчиков» не смогут на бумаге написать корректный http-запрос, о каких тонкостях может идти речь?
В статье нет ни одного пункта напрямую относящегося к ajax, а названа она так лишь потому, что сейчас модно везде вставлять аяксы и прочие вебдваноли.
0
Dargin #
Setti все правильно сказал. Можно еще добавить пункт «кэшируйте запросы, которые возможно». Загрузка за секунду отличается от мгновенной.
+1
Gangsta #
используйте сжатие, это позволит сократить время работы скрипта

Интересно, как сжатие может сократить время работы скрипта?

0
absolvo #
Я не совсем корректно выразился, однако фраза:
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных.
Должна вам объяснить, что имелось ввиду.
0
Imenem #
Ответ от бакэнда в gzip сделать просто, а как произойдет распаковка / обработка его клиентским скриптом? Можно ссылку на описание или рабочий пример?
+1
Angerslave #
Смотря что включать в такой показатель, как время работы скрипта:) Если количество занятых процессорных тактов, то да, даже увеличится(ведь надо сжатые данные ещё распаковать), если время от вызова функции до возвращения ею какого-то значения, то(если, конечно, у пользователя не гигабитный интернет), время сократится, ведь данных придётся передавать меньше. В большинстве несложных JavaScript-скриптиков юзающий XmlHttpRequest главный bottleneck есть получение информации от сервера. Если мы сокращаем время получения этих данных за счёт снижения их размера — мы уменьшаем время работы скрипта. И, думаю, накладные расходы на сжатие(дополнительный заголовок HTTP, распаковка и т.д.) действуют только на сверхмалых(считаные байты) размерах. Поэтому, имхо, этот совет очень оправдан.
–15
Silentium #
Повысил бы вам карму, если б мог, но уже когда-то это сделал.
+1
alexbig #
люблю JSON
0
alexbig #
просто вы не умеете его готовить :)
зачем минусовать-то?
–27
garex #
н4м
0
derbov #
Хотел бы добавить «Проверяйте входящие данные».
Лучше устроить двойную проверку валидности данных — на клиентской стороне и на сервере (от любителей FireBug)
–1
dohlik #
Чем Вас пункты 5 и 6 не устраивают?
0
derbov #
тока подтвердил статью.
+1
DriverX #
Ну в принципе ничего нового, но за напоминание спасибо =)
0
pxx #
Простите, а «с кондачка» — это как?

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