Почему загрузка встроенного JavaScript в представлениях с помощью AJAX плоха?

Question

Почему загрузка встроенного JavaScript в представлениях с помощью AJAX плоха?

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

Оболочка formTabs (вкладки ajax без функций обратного вызова)

...
<script type ="text/javascript">
    var messagingTabset = ProjectName.Tabset.init({
        'tabID': 'preferences-tabset',
        'ajaxUrl0': '<%=Url.Action("PreferencesMainForm", "Profile")%>',
        'ajaxUrl1': '<%=Url.Action("ProfileImageForm", "Profile")%>',
        'ajaxUrl2': '<%=Url.Action("InterestsForm", "Profile")%>',
        'ajaxUrl3': '<%=Url.Action("PrivacyForm", "Profile")%>',
        'ajaxUrl4': '<%=Url.Action("PasswordForm", "Profile")%>',
        'ajaxUrl5': '<%=Url.Action("CustomUrlForm", "Profile", new {userId = Model.UserId})%>',
        'defaultAjaxUrl': '<%=Url.Action(Model.PartialName, "Profile")%>'
    });
</script>
...

представление privacyForm (более встроенный JavaScript с серверным кодом)

...
<script type = "text/javascript">
    var preferencesPrivacyForm = new ProjectName.AJAX.Form({
        "ajaxFormID": "preferences-privacy-form",
        "actionUrl": '<%= Url.Action("SavePrivacy","Profile") %>',
        "dataReturnType":"json"
    });
</script>
...

Внутреннийразработчик: "Код JavaScript конфигурации для этой формы должен оставаться в представлении privacyForm"

Разработчик интерфейса: "Хм, я уверен, что я читал, что это не способ сделать это - ненадежно, весь JavaScript должен быть внутри HTML-страницы, содержащей оболочку вкладок, внутри функции обратного вызова этой вкладки загрузить, Вы действительно должны: а) предоставить мне логику получения динамических данных внутри tabs-wrapper или б) позволить мне получить эти динамические переменные через обход DOM "

Бэкэнд-разработчик: "Оба эти метода - большая работа без реальной отдачи! Первый пример плохой, потому что это означает, что мне придется изменить способ его сборки (и работает нормально). Означает дублирование. Второй пример является хитрым, так как разметка может измениться, поэтому кто-то, работающий над кодом, может забыть отредактировать методы обхода DOM в tabs-wrapper. Это еще один уровень абстракции, который нам не нужен. Если вы предоставите мне с некоторыми доказательствами того, почему это действительно очень плохо, чем я это проверю, но в противном случае я не могу оправдать время "

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

Это один из многих примеров в большом приложении, где мы загружаем встроенный JavaScript с помощью Ajax.

Должен ли я убедить внутреннего разработчика, что мы должны использовать обратные вызовы, или я что-то упустил?

11

javascript ajax xml platform-agnostic

Источник

user150290 16 июн '10 в 08:15

4 ответа

Другие вопросы по тегам javascript ajax xml platform-agnostic

user90811 16 июн '10 в 08:23 2010-06-16 08:23 · Answer 1 · 2010-06-16 08:23

Я бы порекомендовал прочитать "Как завоевывать друзей и оказывать влияние на людей" Дейла Карнеги.

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

Эту книгу определенно стоит прочитать; Абсолют ДОЛЖЕН читать для этой профессии.

user365695 16 июн '10 в 15:16 2010-06-16 15:16 · Answer 2 · 2010-06-16 15:16

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

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

user33890 24 июн '10 в 14:33 2010-06-24 14:33 · Answer 3 · 2010-06-24 14:33

Это основа аргумента о том, почему ненавязчивый Javascript (UJS) хорош. Я никогда не понимал его достоинств, потому что я не знал, как решать проблемы без встроенного Javascript. В конце концов я узнал.

Прежде всего, UJS хорош, потому что он разделяет ваш код переднего плана следующим образом:

HTML - чистый HTML для структурирования вашей информации.
CSS - CSS используется для оформления вашего документа и его оформления.
Javascript - Javascript используется для определения поведения вашей страницы.

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

С помощью инфраструктуры Javascript, такой как jQuery, вы можете динамически связывать обработчики javascript с событиями в различных объектах HTML DOM. Это позволяет вам не делать это встроенным в HTML.

Я работал с кодом, который четко разделен (структура, стиль / макет, поведение), и с кодом, который представляет собой собачий завтрак HTML, CSS и Javascript, включая код HTML/JS, который был динамически создан с использованием ERB. Оба были трудны для понимания по разным причинам. Первый был трудным, потому что я должен был понять, что находится в каждом из файлов, в то время как смешанный код было трудно понять, потому что я должен был выяснить, что такое JS, что такое HTML, что такое CSS, что инициализировалось когда и что был создан. Однако, как только я поехал по кривой обучения, разработка четко разделенного кода стала менее трудоемкой и простой в тестировании.

Для сгенерированного Javascript (например, с помощью ERB) вы обычно можете структурировать код, где у вас есть статический javascript, управляемый некоторыми пользовательскими или контекстно-зависимыми данными. Как предложил предыдущий человек, вы можете просто установить значения для этих данных в разделе HEAD, а затем использовать статические файлы Javascript. Вы также можете использовать вызов AJAX, чтобы получить те же данные с сервера.

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

user323407 21 июн '10 в 19:12 2010-06-21 19:12 · Answer 4 · 2010-06-21 19:12

Из примера не ясно, зачем вам нужен AJAX. Почему бы просто не поставить

<script type ="text/javascript">
    var userId = "<<<<= userId >>>>"
</script>

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