Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 63
В принципе, эти советы подходят ко всем аспектам web-разработки)
Да, выкинуть пару советов (или сделать их более общими), и будут подходить почти ко всем аспектам )
Вот и я также — ожидал что будут написаны советы в духе — используйте json вместо XML для передачи данных — а получил [b]типичные советы для начинающего веб-разработчика[/b].
В принципе эти советы подходят для любой разработки )
Пункт 5 и 6 лишние, не какого отношения к Ajax.
Фреймворки, естественно, ускоряют процесс разработки приложения, но зачастую просто необходимо разрабатывать не универсальные системы, а системы «точечные», узкоспециализированные, оптимизированные под конкретную ситуацию. Правда?
планирование — одно из самых важных правил
Причём в любой области, будь то разработка приложения, или поход в кино с девушкой.
Согласен!
Согласен!
Главное не начать планировать как лучше все спланировать)) Как в том фильме.
неплохо было бы написать ссылочки еще к пару пунктам
Всё что было на Вики — оформил в виде ссылок.
Спасибо!
Внёс в топик.
Внёс в топик.
Незачто) если посмотреть оригинал там есть еще такие ссылочки:
www.w3schools.com/html/
www.w3.org/TR/xhtml1/
www.json.org/
java.sun.com/developer/technicalArticles/J2EE/AJAX/RealtimeValidation/
www.zimbra.com/blog/archives/2006/09/securing_ajax.html
www.w3schools.com/html/
www.w3.org/TR/xhtml1/
www.json.org/
java.sun.com/developer/technicalArticles/J2EE/AJAX/RealtimeValidation/
www.zimbra.com/blog/archives/2006/09/securing_ajax.html
По-моему, в пункте 4, среди стандартов несколько пунктов лишние.
XML и XHTML например.
XML и XHTML например.
Если XHTML и спорный вопрос, то XML отнюдь не лишний.
Насчет XML вы погорячились ;-)
absolvo, croatian:
Для аякса, не вижу его преимуществ перед JSON-ом.
Для аякса, не вижу его преимуществ перед JSON-ом.
Без XML AJAX уже не AJAX, а какой-нить AJAJ…
А, ну, да. Раз уж он так называется, нам ничего не остается, кроме как использовать XML…
Думаю, скорее так исторически сложилось — передавать можно было хоть HTML для вставки сразу в элемент, но всеобщее XML-помешательство тогда было сильно:)
Вот и я о том же. Помешательство и сейчас еще есть, хоть и поменьше.
И XHTML из той же серии «давайте еще куда нибудь ввернем xml, это же так круто!».
И XHTML из той же серии «давайте еще куда нибудь ввернем xml, это же так круто!».
Хм, хоть это и из другой оперы, но для меня теги в стиле
это такой же анахронизм, как и … Поэтому из HTML и XHTML я выбираю последнее:)
это такой же анахронизм, как и … Поэтому из HTML и XHTML я выбираю последнее:)
XHTML нужен хотя бы для XSL преобразований, чтобы из XML получить веб-страницу.
Ну это вынужденный XHTML. Не развалидировать же его!
XSL — инструмент для преобразования любого XML в любой XML. В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто». А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.
Вам не кажется, что в этой логике есть какой-то изъян? =)
XSL — инструмент для преобразования любого XML в любой XML. В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто». А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.
Вам не кажется, что в этой логике есть какой-то изъян? =)
В качестве «шаблонизатора» данных в HTML он не очень подходит, а используют его, потому что «XML — это круто».
Категорические утверждения редко бывают верными.
А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.
Мне, как разработчику, в принципе, всё равно какой именно протокол выбран IT сообществом стандартом (или одним из стандартов). Для меня имеет значение, что этот стандарт начинает поддерживаться в самых разных системах, что позволяет мне эффективно эти системы объединять в рамках одного проекта.
Например, используя XML я могу получить данные из хранимой процедуры в MS SQL 2005 в виде XML документа, затем применить к полученным данным XSL шаблон и получить XHTML документ, который посылается пользователю. В данном случае, производители БД, серверных библиотек и клиентского браузера поддержили один и тот же стандарт, что позволяет мне делать сложные вещи просто.
Если бы это был бы не XML, а JSON или вообще какой-то бинарный протокол, я бы не возражал, главное чтобы стандарт поддерживался как можно более большим количеством участников IT индустрии.
Разумеется, выбирая что-то в качестве стандарта для широго круга задач, невозможно выбрать что-то, что будет наиболее оптимальным для каждой конкретной задачи. Это может дать возможность говорить, что этот стандарт «плохой», а повсеместное использование стандарта называть «помешательством», как вы изволили написать выше, но я бы обратил внимание, что именно повсеместное использование и делает стандарт стандартом и позволяет единообразно работать с довольно разными системами.
Категорические утверждения редко бывают верными.
А «XML — это круто», потому что для него разработана масса технологий, например XSL и AJAX.
Мне, как разработчику, в принципе, всё равно какой именно протокол выбран IT сообществом стандартом (или одним из стандартов). Для меня имеет значение, что этот стандарт начинает поддерживаться в самых разных системах, что позволяет мне эффективно эти системы объединять в рамках одного проекта.
Например, используя XML я могу получить данные из хранимой процедуры в MS SQL 2005 в виде XML документа, затем применить к полученным данным XSL шаблон и получить XHTML документ, который посылается пользователю. В данном случае, производители БД, серверных библиотек и клиентского браузера поддержили один и тот же стандарт, что позволяет мне делать сложные вещи просто.
Если бы это был бы не XML, а JSON или вообще какой-то бинарный протокол, я бы не возражал, главное чтобы стандарт поддерживался как можно более большим количеством участников IT индустрии.
Разумеется, выбирая что-то в качестве стандарта для широго круга задач, невозможно выбрать что-то, что будет наиболее оптимальным для каждой конкретной задачи. Это может дать возможность говорить, что этот стандарт «плохой», а повсеместное использование стандарта называть «помешательством», как вы изволили написать выше, но я бы обратил внимание, что именно повсеместное использование и делает стандарт стандартом и позволяет единообразно работать с довольно разными системами.
Ловите плюс в карму. Приятно читать грамотные комменты грамотного человека.
В вашем случае, конечно, против XMLа выступать глупо.
Но я же говорил не про ваш случай. Если в нем заменить MS SQL 2005 на «обычный порошок» то вся стройная картина, увы, рушится. Да и редко бывает, что бы результат запроса к БД можно было без дополнительно обработки отправлять в js.
Я же не предлагаю использовать JSON везде и всегда, я предлагаю думать головой (что конкретно вы, по-видимому, и делаете), а не использовать XML везде и всегда. И утверждаю, что для большинства задач, от использования XML нет ни какой пользы, акромя вреда.
Про «помешательство»: стандарт не бывает плохим. Но бывает, что он становится настолько раскрученным, что многие его начинают использовать не для упрощения, а наоборот. И как назвать поведение этих многих?
Но я же говорил не про ваш случай. Если в нем заменить MS SQL 2005 на «обычный порошок» то вся стройная картина, увы, рушится. Да и редко бывает, что бы результат запроса к БД можно было без дополнительно обработки отправлять в js.
Я же не предлагаю использовать JSON везде и всегда, я предлагаю думать головой (что конкретно вы, по-видимому, и делаете), а не использовать XML везде и всегда. И утверждаю, что для большинства задач, от использования XML нет ни какой пользы, акромя вреда.
Про «помешательство»: стандарт не бывает плохим. Но бывает, что он становится настолько раскрученным, что многие его начинают использовать не для упрощения, а наоборот. И как назвать поведение этих многих?
Про «помешательство» не вы писали, прошу прощения
xslt трансформация на клиенте, явное преимущество
Куда важнее для ajax-разработчика знать, что
1) JS-ссылки должны работать и с выключенным JS.
2) Должна работать кнопка «Назад».
3) Полезный «ajax-контент» не должен быть скрытым для поисковиков.
4) Отображать индикацию процесса.
А то, что в топике — это не про ajax.
1) JS-ссылки должны работать и с выключенным JS.
2) Должна работать кнопка «Назад».
3) Полезный «ajax-контент» не должен быть скрытым для поисковиков.
4) Отображать индикацию процесса.
А то, что в топике — это не про ajax.
Чтобы мой бэкэнд скрипт не валили обычными пост запросами я в него втыкаю такой код:
if($_SERVER['HTTP_X_REQUESTED_WITH'] != 'XMLHttpRequest') die(«Ай нанэ нан»);
Ну это «защита» от ленивых хакеров. умный всегда найдет)
if($_SERVER['HTTP_X_REQUESTED_WITH'] != 'XMLHttpRequest') die(«Ай нанэ нан»);
Ну это «защита» от ленивых хакеров. умный всегда найдет)
Что за профессия такая, ajax-разработчик? Я понимаю web или javascript, но ajax… Это типа человек который не знает js, но знает как работает XmlHttpRequest?
Вот справа смотрю на вакансии вижу там PHP-программист, С Developer, python developer.
Почему-то никто не ищет stdio.h-разработчиков или UserString-разработчиков.
Вот справа смотрю на вакансии вижу там PHP-программист, С Developer, python developer.
Почему-то никто не ищет stdio.h-разработчиков или UserString-разработчиков.
AJAX включает в себя не только JavaScript, поэтому тонкости технологии XML, протокола HTTP и ещё разные другие вещи не менее важны, чем непосредственно знание JavaScript. Хотя AJAX-разработчик я тоже редко встречаю, чаще frontend-developer.
XML нужно знать ровно настолько чтобы перестать использовать его без крайней на то необходимости (тот же JSON в большинстве случаев будет удобнее и быстрее). Если уж XML так необходим, то объяснить программисту, что это такое можно за несколько минут. В рамках использования его в ajax — это всего лишь еще один формат хранения данных, не более.
Тонкости HTTP? Большинство сегодняшних «ajax-разработчиков» не смогут на бумаге написать корректный http-запрос, о каких тонкостях может идти речь?
В статье нет ни одного пункта напрямую относящегося к ajax, а названа она так лишь потому, что сейчас модно везде вставлять аяксы и прочие вебдваноли.
Тонкости HTTP? Большинство сегодняшних «ajax-разработчиков» не смогут на бумаге написать корректный http-запрос, о каких тонкостях может идти речь?
В статье нет ни одного пункта напрямую относящегося к ajax, а названа она так лишь потому, что сейчас модно везде вставлять аяксы и прочие вебдваноли.
используйте сжатие, это позволит сократить время работы скрипта
Интересно, как сжатие может сократить время работы скрипта?
Интересно, как сжатие может сократить время работы скрипта?
Я не совсем корректно выразился, однако фраза:
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных.
Должна вам объяснить, что имелось ввиду.
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных.
Должна вам объяснить, что имелось ввиду.
Смотря что включать в такой показатель, как время работы скрипта:) Если количество занятых процессорных тактов, то да, даже увеличится(ведь надо сжатые данные ещё распаковать), если время от вызова функции до возвращения ею какого-то значения, то(если, конечно, у пользователя не гигабитный интернет), время сократится, ведь данных придётся передавать меньше. В большинстве несложных JavaScript-скриптиков юзающий XmlHttpRequest главный bottleneck есть получение информации от сервера. Если мы сокращаем время получения этих данных за счёт снижения их размера — мы уменьшаем время работы скрипта. И, думаю, накладные расходы на сжатие(дополнительный заголовок HTTP, распаковка и т.д.) действуют только на сверхмалых(считаные байты) размерах. Поэтому, имхо, этот совет очень оправдан.
Повысил бы вам карму, если б мог, но уже когда-то это сделал.
люблю JSON
н4м
Хотел бы добавить «Проверяйте входящие данные».
Лучше устроить двойную проверку валидности данных — на клиентской стороне и на сервере (от любителей FireBug)
Лучше устроить двойную проверку валидности данных — на клиентской стороне и на сервере (от любителей FireBug)
Ну в принципе ничего нового, но за напоминание спасибо =)
Простите, а «с кондачка» — это как?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
9 правил для начинающего Ajax-разработчика