Сколько контента заменяется вызовом AJAX - это слишком много? - PullRequest
3 голосов
/ 08 января 2009

Я сталкиваюсь с общей проблемой при попытке разработки AJAX. Где это возможно, я хотел бы попробовать обновить данные в существующем макете, а не в самом макете. Например, возьмите div ниже:

<div id="content-5">Here is some content</div>

Я бы получил обновленное значение для content-5 с сервера и просто заменил бы содержимое content-5 значением. Это имеет большой смысл для простых замен данных, когда значение всегда будет отображаться в чистом виде.

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

Пример. Поле состояния из контроллера возвращается как «завершено», но из документа конструктора «завершено» должно показывать пользователю текст «Доступен», и его нужно стилизовать не так, как другие. статусы.

Выполнение этого в Javascript потребовало бы некоторого углубленного знания представления, которое, вероятно, уже обрабатывает слой шаблона. Конечный результат будет таким же (фрагмент кода ниже), но разница в том, что может быть некоторое дублирование кода и гораздо более сложный слой Javascript.

<div id="content-5"><span class="success">Available</span></div>

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

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

<div id="allContent">
    <div id="content-1">Some content A</div>
    <div id="content-2">Some content B</div>
    <div id="content-3">Some content C</div>
    <div id="content-4">Some content D</div>
    <div id="content-5">Some content E</div>
</div>

В какой-то момент я должен задаться вопросом: где линия? В какой-то момент я чувствую, что в конечном итоге я просто заменю всю страницу запросом AJAX. Неужели это действительно проблема?

Я понимаю, что это может быть довольно субъективно, но каковы хорошие стратегии для определения, на каком уровне вы должны заменять контент на AJAX? Замена только данных кажется моим предпочтительным методом, когда это возможно, поскольку это делает контроллеры AJAX очень простыми. Замена больших фрагментов HTML из шаблона кажется наиболее простой для решения более сложных проблем макета и дизайна, а также ощущается, что ее легче обслуживать. Есть ли другие варианты, которые я не рассматривал?

Я ожидаю, что будет некоторое обсуждение программного управления DOM, но мне лично это очень не нравится. Код в конечном итоге выглядит довольно ужасно и действительно начинает интегрировать слишком много разметки и дизайна в слой JS на мой взгляд. Поскольку я обычно работаю с библиотеками шаблонов какого-либо типа (будь то сырой PHP, шаблоны PHP, такие как Smarty или JSP в Java), кажется, имеет больше смысла оставлять там как можно больше визуального дизайна.

EDIT

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

Ответы [ 6 ]

2 голосов
/ 08 января 2009

Я думаю, что наиболее важным требованием является требование обновления. Если после нескольких обновлений AJAX я нажму «обновить», то страница, на которую я только что посмотрел, должна быть той страницей, которая появляется. Если по какой-либо причине страница возвращается в предыдущее состояние, значит, URL неверный. Если по какой-либо причине ваши AJAX-данные сделают URL-адрес в браузере недействительным, вам не следует использовать AJAX для получения этих данных.

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

2 голосов
/ 08 января 2009

Полное личное мнение ex nihil , мое эмпирическое правило заключается в том, чтобы изменить не более 1 "панели" или 33% страницы в зависимости от того, что меньше .

Основой для этого является то, что пользователь должен иметь возможность четко распознать, что предыдущее состояние страницы связано с новым состоянием - как бы вы себя чувствовали, если бы вас внезапно телепортировали в здание справа от вас? Будьте осторожны со своим бедным пользователем.

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

Ваш конкретный вопрос, по-видимому, зависит от предположения, что ответ, возвращаемый на ваш запрос AJAX, не является "просто" данными. Мне кажется, что это неправильно с точки зрения разделения интересов: я ожидаю, что страница будет иметь всю информацию о макете, которая ему уже требуется, сам ответ AJAX не даст ничего, кроме глупых данных / разметки, и обработчик события JS, который просьба сшить их вдвоем, стиль MVC. В этом отношении, я думаю, да, ты слишком много делаешь.

(под панелью я имею в виду один логический элемент дизайна - меню, ленту, панель метаданных элемента и т. Д.)

edit: теперь, когда я думаю об этом, я думаю, что страница профиля пользователя SO нарушает мое эмпирическое правило с этими щелчками вкладки

0 голосов
/ 08 января 2009

Если бы вы обычно заменяли все содержимое страницы вызовами AJAX, я бы согласился, что у вас есть проблема. Тем не менее, мне кажется, что вы пытаетесь тщательно продумать последствия вашего дизайна и стараетесь, где это возможно, избегать того, что аннаката назвал «анти-паттерном AJAX».

Мое правило немного проще: до тех пор, пока на странице остается значительный объем контекста (например, меню слева, заголовок, различные элементы управления, заголовок страницы и т. Д.), Я согласен с заменой почти всего на AJAX звонок. Тем не менее, я никогда не боролся со страницей, в которой было бы столько же AJAX-сгенерированного кода, сколько и у вас.

У меня есть один вопрос: разве нельзя кодировать состояние, чтобы вы могли просто заменить некоторые элементы Div в своем примере, а не все? Если нет, задумывались ли вы об этом?

0 голосов
/ 08 января 2009

Если вы используете шаблоны Smarty для создания страницы, просто разбейте шаблон на несколько значимых разделов - news.tpl, email.tpl, weather.tpl - и получите master.tpl, создающий структуру страницы и вызывающий дочерние шаблоны.

Затем, если вы, например, используете вызов AJAX, инициируемый тайм-аутом, чтобы обновить новости, вы можете просто вызвать сервер, собрать необходимые данные в news.tpl и вернуть результаты в заданный вами div новостей. с master.tpl. Таким образом, ваш макет новостей всегда следует шаблону news.tpl. (Если вы использовали JavaScript для манипулирования битами форматирования или для настройки обработки событий при загрузке документа, вам необходимо подключить эту постобработку к запуску после вызова AJAX.)

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

Сколько форматирования выполняется на стороне сервера по сравнению с тем, сколько выполняется на стороне клиента с помощью JavaScript? Я бы сказал, если это возможно, на стороне сервера, если у вас есть код, который отражает дискуссии о компоновке и логике дисплея. Форматирование на стороне клиента может использоваться для решения других проблем, связанных с интерфейсом - сортировка строк в таблице и чередование цветов строк с помощью: нечетных и: четных селекторов, показ и скрытие элементов div для создания «отображения с вкладками» без попадания на сервер, поскольку данные не просто выбрать новую вкладку и все такое.

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

0 голосов
/ 08 января 2009

Хорошая рекомендация для чего-то подобного - спросить себя: «Является ли это динамическое приложение« контентом »или контент-контентом?» Ваш вариант использования звучит как контент приложения, который будет меняться с каждым пользователем. Это, пожалуй, лучшее место для Ajax, но со всем всегда приятно не иметь только один молоток. Вы не хотите делать слишком много на одной странице. Например, если одна часть сломается, то все это может привести к разочарованию пользователя.

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

0 голосов
/ 08 января 2009

В зависимости от того, хотите ли вы, чтобы люди могли ссылаться на / закладки и т. Д. На текущей странице, вы можете перейти в браузер пользователя.

Это не касается некоторых приложений, таких как GMail и т. Д., И они никогда не обновят страницу.

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

Извините, если это расплывчато, это довольно субъективно: -)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...