Привет, ребята, у меня вопрос, который кажется глупым, но я не могу сказать, почему.
Представьте себе webapp с пользователями и тегами. Пользователи отмечают друг друга.
У меня есть одна страница в приложении, которая отображает подробности об одном теге по отношению к одному пользователю. Пусть говорят " bob" и тег footag. На этой странице я показываю два списка: все люди, которые отметили bob с помощью "footag" и всех людей bob, отметили "footag". назовите эти <div id="received'> и <div id="sent">
Предположим, что для этого представления URL /users/bob/tags/footag
Естественно, эти списки длинны - я не хочу загружать весь список на просмотр страницы. Поэтому я загружаю первую десятку для каждого.
Теперь я могу предоставить динамический пейджинг для каждого из списков одним из двух способов:
div./users/bob/tags/footag/received?page=1. Я получаю его асинхронно и просто заменяю содержимое соответствующего <div>.Итак, в одном случае я извлекаю данные и обрабатываю их через JS в браузере, а другой - получаю данные и просто выкладываю их в документ.
Есть ли причина не использовать # 2? Я не могу себе представить, но я полагаю, что могут быть аспекты безопасности, которые я не рассматриваю, или производительность, или что-то еще. Я бы предпочел сделать # 2, поскольку это значительно упростило мою жизнь.
Спасибо!
У меня есть приложение вроде этого - я использую оба метода.
Я использую ваш метод # 1 для обновления полей, которые не являются смежными (например, поля ввода по всему месту), но я использую ваш метод # 2 для обновления табличных данных, вроде ваших списков.
Я бы придерживался №2 для вашего дела.
я бы пошел С# 1... так что вы действительно получите данные, а не только некоторые HTML... это будет просто краткая структура объектов JavaScript, а не какая-то строка, поэтому вы можете оценить данные по своему усмотрению, кешировать его, использовать его для поиска и т.д.... чем больше работы выполняется на стороне клиента, тем лучше, тем лучше, чем вы масштабируете приложение... у вас есть 1 сервер, или, возможно, 2-10 или я не знаю, но у вас 10-10000 клиентов...
Greetz
back2dos
Я лично использовал бы метод # 2. Зачем тратить время на парсинг на стороне клиента, который может быть легко и лучше, если использовать серверный язык? Вместо того, чтобы создавать массив, а затем преобразовывать его в json, было бы гораздо лучше просто пропустить результаты и эхо-HTML.
Я бы оценил его в нескольких браузерах, но я подозреваю, что # 1 (передача как JSON) может оказаться быстрее. С помощью этого метода вы можете просто заменить значения для существующих узлов DOM. Например. (очень упрощенное) изменение (непосредственно с помощью DOM-манипуляции):
<li>foo</li>
<li>bar</li>
<li>baz</li>
в
<li>foo2</li>
<li>bar2</li>
<li>baz2</li>
когда вы получаете JSON:
["foo2", "bar2", "baz2"]
Таким образом, вы не создаете новые узлы DOM без необходимости. Другим преимуществом является то, что JSON API более "аппетитный", если позже вы решите сделать его общедоступным в той или иной форме.
хорошо, кроме небольших накладных расходов на форматирование, загружаемое с сервера, что может сделать его немного медленнее для большого количества данных, я не вижу недостатков. И поскольку рендеринг javascript, вероятно, будет слишком медленным, я бы пошел С# 2.
Я говорю # 1 для большинства случаев. Если вы хотите добавить кнопку "next/prev" за пределами обновляемого div, вы можете использовать JS для определения, когда включать/отключать их. Использование # 1 дает вам большую гибкость и дополнительно отделяет данные от презентации.
Производительность и "простота разработки" на мой взгляд пренебрежимо мала. Производительность не слишком велика для небольших "кусков" данных (при условии, что ваш JS включен в сферу здравомыслия) и "простота разработки" не является большим фактором, учитывая, что это легче поддерживать.