Как установить другой путь baseUrl в jQuery-запросах ajax в режиме разработки и производства?

Question

Мой путь baseUrl для jQuery ajax-запросов отличается в режиме разработки и производства. Как я могу установить его в какой-то файл config.ini, чтобы легко его переключать. Теперь я использую файл baseurl.js, содержащий только путь baseurl. В производственном режиме я изменяю эту переменную через скрипт оболочки.

Какой должен быть лучше подход?

редактировать

Чтобы сделать вещи немного яснее,

 $.ajax({
   type: "GET",
   url: myurl,
   dataType: "script"
 });

Здесь «myurl» var отличается для производства и разработки.

PS: Мой вопрос не о контроле версий или не упаковывании файлов в один.

Answer 1

Если вы используете технологию динамических страниц (asp, php, ...), то вы можете превратить ваш baseurl.js файл в динамический, такой как baseurl.js.php, и внутри него вывести текущий URL. ( если это то, что вы спрашиваете ).

• для php посмотрите на $ _ SERVER
• для asp посмотрите на Request.ServerVariables

Answer 2

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

Чтобы избежать ошибок при запуске, я создал сценарий оболочки, содержащий аргументы командной строки для YUI, который запускается перед развертыванием. Это также идеальное место для ссылки на любые производственные файлы JavaScript - например, вы можете создать файл production.js, который задает ваш путь baseurl и включить его в командную строку.

Answer 3

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

Answer 4

Использование системы контроля версий будет лучшим подходом.

У вас будет один файл конфигурации, и каждый клиент может "проверить его" и изменить его по своему усмотрению в соответствии со своей средой (разработка, тестирование, производство и т. Д.).

Вероятно, вы настроите производственную конфигурацию для вашей системы контроля версий, и у вас будет настроенная версия в среде разработки. Только не регистрируйте свою настроенную версию на сервере контроля версий.

Я не знаю, в какой операционной системе вы работаете, но я бы порекомендовал TortoiseSVN (для Windows) и Beanstalk (размещенная служба Subversion), чтобы начать работу с минимальные усилия Если вы предпочитаете настроить свой собственный сервер SVN, VisualSVN делает это тривиальной задачей.

И вуаля, не надо больше менять конфигурацию!