Включить данные JSON в строку или из отдельного вызова AJAX? - PullRequest
Новая
       1

Включить данные JSON в строку или из отдельного вызова AJAX?

1 голос
/ 06 мая 2011

Я работаю над веб-сайтом, на котором "домашняя" страница пользователя содержит некоторые данные для использования с помощью обширного кода JavaScript.В настоящее время данные кодируются в виде объекта JSON в теге сценария в конце тела документа, и объект управления GUI создается сразу после этого, чтобы он имел доступ как к DOM, так и к объекту JSON.Мне нравится эта структура, потому что она позволяет быстро загружать страницу.Это выглядит примерно так: 

<body>
  <script type="text/javascript" src="mylib.js"></script>
  <div>...lots of DOM and text content...</div>
  <script type="text/javascript">
    var userData = {...}; // Encoded by HTTP response handler.
    $(document).ready(function() {
      // GUI object which modifies form controls, etc.
      new MyGuiObject(userData, document.form.myForm);
    };
  </script>
</body>

Однако для новой функциональности может потребоваться, чтобы объект userData возвращался как отдельный HTTP-запрос, что означает, что встроенная форма будет дубликатом (и нарушение Принцип СУХОГО ).Соблазнительно реорганизовать приведенный выше код для использования этого AJAX-запроса для userData, но он вводит еще один HTTP-запрос данных, который, как мы знаем, необходим (и доступен) немедленно.

Стоит ли менять код для использования userDataизвлечены из вызова AJAX?Если да, то какой метод рекомендуется использовать для кодирования URL-адреса, из которого извлекаются данные (учитывая, что он будет лучше динамически генерироваться веб-структурой)?

Ответы [ 2 ]

1 голос
/ 06 мая 2011

Стоит ли менять код для использования userData, полученного из вызова AJAX?

Я бы так не думал, но это будет вопросом мнения инесколько зависит от вашей общей среды.Это оценочный вызов.

При условии, что у вас есть базовый код, который генерирует объект (будь то в начальном элементе script или позже в ответ на вызов ajax), вы не нарушаете принцип DRY.

Если HTML-страница, на которой она появляется, является полностью статичной (и, следовательно, кэшируемой), то вы будете повторяться, как если бы вам сначала понадобилось поместить объект в HTML, а затем снова создать его с динамическим ответом.на запрос AJAX.Но если исходный HTML уже сгенерирован динамически, то просто используйте центральную функцию для генерации объекта в обоих случаях.(Функция может генерировать строку в формате JSON, затем на странице HTML просто вывести ее с var userData = перед ней, поскольку JSON является подмножеством литерального формата объекта JavaScript, и поэтому вы можете поместить его в скрипт, где литерал объектадопустимо.)

СУХОЙ или нет, я не хотел бы добавлять HTTP-запрос, которого можно было бы избежать, к загрузке моей страницы.

Если это так, то какой метод является лучшим для кодированияURL, с которого извлекаются данные ...

Я не совсем уверен, что вы подразумеваете под кодированием URL.Если вы имеете в виду ответ, содержащий JSON, просто отправьте его обратно с Content-Type: application/json.jQuery поймет это и десериализует его в объект для вас, прежде чем передать его вашей функции success.

0 голосов
/ 06 мая 2011

Однако новая функциональность может потребовать, чтобы объект userData возвращался как отдельный HTTP-запрос, что означает, что встроенная форма будет дубликатом (и нарушением принципа DRY).Соблазнительно реорганизовать приведенный выше код для использования этого AJAX-запроса для userData, но он вводит еще один HTTP-запрос данных, который, как мы знаем, необходим (и доступен) немедленно.

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

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

Стоит ли менять код для использованияuserData получена из вызова AJAX?

Похоже, вы говорите выше, что это потребуется, нет?Если это так, зачем вам нужно, чтобы он был принят асинхронно?Собираете ли вы данные с другого сайта и хотите как можно быстрее передать содержимое пользователю, а затем обновить его этой дополнительной информацией?В противном случае, для оптимальной производительности, вероятно, будет лучше предоставлять пользовательские данные непосредственно пользователю, а не ждать их ответа Ajax, поскольку Ajax лучше всего использовать для данных, необходимых позже в приложении, особенно с учетом ограничений IE <8 вобработка более двух одновременных подключений. </p>

Если вам нужен Ajax, возможно, вы сможете предоставить некоторую информацию о загрузке, а затем использовать дополнительные данные, возвращенные Ajax.

ЕслиИтак, какова лучшая практика для кодирования URL-адреса, из которого извлекаются данные (учитывая, что он будет лучше динамически генерироваться веб-структурой)?

Что вы подразумеваете под кодированием URL-адреса?точно?

Вы имеете в виду кодирование символов URL?В Core JavaScript это обычно делается с помощью encodeURIComponent () , хотя в jQuery это может быть обработано для вас такими методами, как serialize () и jQuery.param (), с первым для сериализации существующей формы в закодированный URL, а вторым для получения массива или объекта в кодированном URL-формате.

Если вы имеете в виду выбор между GET или POST, GET должениспользовать, если ваш поиск не имеет побочных эффектов на сервере, а POST в большинстве случаев - то, что вы должны использовать в противном случае.

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

Нет похожих вопросов

...