Здесь есть несколько отличных решений, но я хотел бы сделать еще один шаг в отношении локального файла.
В случае, если Google не работает, он должен загрузить локальный источник, но, возможно, физический файл на сервере не обязательно является лучшим вариантом. Я поднял этот вопрос, потому что в настоящее время я реализую то же решение, только я хочу вернуться к локальному файлу, который генерируется источником данных.
Мои причины в том, что я хочу иметь некоторый разум, когда дело доходит до отслеживания того, что я загружаю из Google, и того, что у меня есть на локальном сервере. Если я хочу изменить версии, я хочу, чтобы моя локальная копия синхронизировалась с тем, что я пытаюсь загрузить из Google. В среде, где есть много разработчиков, я думаю, что лучшим подходом было бы автоматизировать этот процесс, чтобы все, что нужно было сделать, это изменить номер версии в файле конфигурации.
Вот мое предлагаемое решение, которое должно работать теоретически:
- В файле конфигурации приложения я буду хранить 3 вещи: абсолютный URL-адрес для библиотеки, URL-адрес для JavaScript API и номер версии
- Напишите класс, который получает содержимое файла самой библиотеки (получает URL из конфигурации приложения), сохраняет его в моем источнике данных с именем и номером версии
- Напишите обработчик, который извлекает мой локальный файл из БД и кэширует файл, пока не изменится номер версии.
- Если это изменится (в конфигурации моего приложения), мой класс извлечет содержимое файла на основе номера версии, сохранит его как новую запись в моем источнике данных, затем обработчик включит и предоставит новую версию.
Теоретически, если мой код написан правильно, все, что мне нужно сделать, это изменить номер версии в конфигурации моего приложения, а затем - альт! У вас есть запасное решение, которое автоматизировано, и вам не нужно хранить физические файлы на вашем сервере.
Что все думают? Возможно, это излишне, но это может быть элегантный способ поддержки ваших библиотек AJAX.
Acorn