Наилучшая практика для реализации Ajax?

Question

В этом руководстве Microsoft они реализуют Ajax на последнем шаге: «Шаг 7. Реализация Ajax»

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

Я внедряю ajax по ходу дела, но мне интересно, что люди считают лучшей практикой в ​​этом отношении. Лучше ли включить Ajax в конце или вы должны реализовать его по ходу дела? Кто-нибудь сталкивался с проблемой так или иначе?

Answer 1

Если ваши основные пользовательские взаимодействия будут опираться на Ajax (например, Google Docs), то вы должны реализовать эти биты раньше.

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

Answer 2

Аргумент за выполнение AJAX последним заключается в том, что у вас гораздо больше шансов разработать сайт, который изящно деградирует, если сначала он заработает без AJAX.

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

Answer 3

Что означает «как ты ходишь»? Я начинаю с дизайна, и поэтому очень ясно, каким будет конечный продукт. Так что, да, вам нужно знать, где происходит AJAX с самого начала.

Answer 4

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

Answer 5

Игнорируя тот факт, что вы ожидаете, что требование Ajax выйдет за пределы требований спецификации пользовательского интерфейса (если у вас есть такая вещь), я бы подумал о ее реализации (или реализации хуков) раньше, чем позже .

1) ретроспективная подгонка к чему-то, что было спроектировано для возврата полных страниц, не обязательно будет простым

2) это потенциально повлияет на схему развертывания вашего решения в том смысле, что оно будет обслуживать страницы плюс фрагменты / объекты страниц, и эти фрагменты приведут к гораздо большему количеству попаданий на ваш сервер (представьте себе дополнительные попадания, которые ваш сервер получит, если вы введете что-то вроде Google Suggest , где потенциально каждое нажатие клавиши может привести к новому запросу сервера).

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

Answer 6

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

Answer 7

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

Я помню, как читал вначале с помощью ajax, чтобы реализовать ваш сайт так, как если бы у браузера вашего пользователя не было javascript, а затем, когда все функции заработали, добавьте ajax, чтобы улучшить взаимодействие с пользователем. Но с первых дней существования AJAX Google определенно выдвинул конверт, и многие люди хотят создавать на своих веб-сайтах эти удивительные возможности для пользователей с помощью AJAX. Я работал со многими людьми, которым действительно нравится реализовывать многие из своих функций в ajax, но лишь немногие из них могли сделать это. У меня, конечно, нет своих отбивных, и я очень расстроен плохо проверенными функциями, которые выглядят действительно круто ... если вы используете их таким определенным образом ... скрестите пальцы. Многое из этого связано с тестированием, модульное тестирование - это одно, в браузерном тестировании - другое, и довольно часто я очень усердно работаю над тем, чтобы внедрить модульные тесты, не говоря уже о целом в наборе для тестирования браузеров.

Вы должны решить, каким должен быть ваш пользовательский опыт, как ajax вписывается в это решение, а затем выбрать, когда внедрять ajax. Ранее для сайтов с основными функциями, реализованными только в ajax, позже для сайтов, где ajax просто добавляет сахар UX. Это мои 0,02 доллара, я уверен, что есть кто-то с противоположным мнением.