Comments 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, а названа она так лишь потому, что сейчас модно везде вставлять аяксы и прочие вебдваноли.
UFO just landed and posted this here
используйте сжатие, это позволит сократить время работы скрипта
Интересно, как сжатие может сократить время работы скрипта?
Интересно, как сжатие может сократить время работы скрипта?
Я не совсем корректно выразился, однако фраза:
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных.
Должна вам объяснить, что имелось ввиду.
Если объёмы передаваемой информации предполагаются не маленькими — то используйте сжатие, это позволит сократить время работы скрипта, за счёт снижения времени передачи данных.
Должна вам объяснить, что имелось ввиду.
Смотря что включать в такой показатель, как время работы скрипта:) Если количество занятых процессорных тактов, то да, даже увеличится(ведь надо сжатые данные ещё распаковать), если время от вызова функции до возвращения ею какого-то значения, то(если, конечно, у пользователя не гигабитный интернет), время сократится, ведь данных придётся передавать меньше. В большинстве несложных JavaScript-скриптиков юзающий XmlHttpRequest главный bottleneck есть получение информации от сервера. Если мы сокращаем время получения этих данных за счёт снижения их размера — мы уменьшаем время работы скрипта. И, думаю, накладные расходы на сжатие(дополнительный заголовок HTTP, распаковка и т.д.) действуют только на сверхмалых(считаные байты) размерах. Поэтому, имхо, этот совет очень оправдан.
Повысил бы вам карму, если б мог, но уже когда-то это сделал.
люблю JSON
н4м
Хотел бы добавить «Проверяйте входящие данные».
Лучше устроить двойную проверку валидности данных — на клиентской стороне и на сервере (от любителей FireBug)
Лучше устроить двойную проверку валидности данных — на клиентской стороне и на сервере (от любителей FireBug)
Ну в принципе ничего нового, но за напоминание спасибо =)
Простите, а «с кондачка» — это как?
Sign up to leave a comment.
9 правил для начинающего Ajax-разработчика