Как локально протестировать междоменные сборки? - PullRequest
Новая
       22

Как локально протестировать междоменные сборки?

3 голосов
/ 17 декабря 2009

С помощью инструментария dojo, как правильно локально тестировать код, который будет выполняться как междоменный, без фактической сборки?

Как представляется, существует три возможных варианта (каждый со своими недостатками):

  1. Использование локального (не xd) XMLHttpRequest dojo.require
    • Эта опция на самом деле не проверяет поведение xd, поскольку она dojo.require [s] js синхронно через XHR.
  2. djConfig.debugAtAllCosts = true;
    • Хотя эта опция загружает требуемый код асинхронно (через тег 'script'), она также извлекает код через XHR, анализирует внутри него dojo.require [s] и извлекает их. Это (используя loader_debug), опять же, это не то, что делает loader_xd. Больше информации по этой теме в другом вопросе.
  3. Создание междоменной сборки
    • Этот подход требует сборки, которая невозможна в среде, в которой я запускаю код (мы используем наш собственный процесс сборки на лету, который включает только js, необходимый для конкретного с. Этот процесс не подходит для разработки).

Таким образом, мой вопрос: есть ли способ использовать loader_xd, который не требует сборки xd (которая добавляет префикс / суффикс xd к каждому файлу)?

Второй способ (с использованием debugAtAllCosts) также заставляет меня усомниться в мотивации предварительного анализа dojo.require [s]. Если loader_xd не будет (или, скорее, не сможет) предварительно анализировать, почему метод, созданный для тестирования / отладки, делает это так?

Ответы [ 2 ]

3 голосов
/ 18 декабря 2009

Пеллер описал ситуацию. Если вы хотите просто сгенерировать файл .xd.js для своих модулей, вы можете посмотреть на util / buildscripts / jslib / buildUtilXd.js и его функцию buildUtilXd.xdgen ().

Чтобы создать собственный скрипт, потребовалось бы немало усилий, но вы можете посмотреть на util / buildscripts / build.js для указателей.

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

1 голос
/ 17 декабря 2009

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

debugAtAllCosts предназначен специально для решения проблемы отладки, когда большинство браузеров до недавнего времени не могли делать ничего умного с кодом, введенным через eval. Еще сегодня Firefox будет сообщать об исключении в консоли как о появлении на сайте eval (bootstrap.js) со смещением номера строки относительно eval, а не из фактического буфера eval, и обычно этот eval-буфер является анонимным. Firebug был первым отладчиком , который перепрыгнул через несколько обручей , чтобы расширить возможности отладки и разрешил специальные метаданные, которые загрузчик Dojo вставляет между XHR и eval, чтобы определить путь к файлу источника. Webkit / Safari недавно также реализовали это. Я полагаю, что debugAtAllCosts предшествует загрузчику XD.

...