У нас работает новый грузчик. Его зовут Фазекс. В этот раз мы коснулись проблемы, которую не рассматривали очень давно. Речь идёт о механизме загрузки Zanas-приложений. В самом начале это делалось так: на старте проекта создавался модуль MY_APPLICATION, смысл которого был исключительно в том, чтобы застолбить имя пакета и загрузить туда подпрограммы из Zanas.pm, а также прикладных модулей. Ветераны ещё помнят те времена, когда при каждой правке приходилось рестартовать Apache для перезагрузки модулей. Позже загрузка приложений стала динамической: появилась процедура require_fresh и опция $preconf -> {core_spy_modules}. В том, что касается MY_APPLICATION::Config, MY_APPLICATION::Calendar, Content и Presentation, наша require_fresh полностью заменила стандартные use/require, однако в остальном изменений не было никаких. С течением времени стали проявляться некоторые досадные ограничения, большинство из которых было обусловлено жёсткой провязкой между именем пакета (типа MY_APPLICATION) и собственно приложением. При попытке использовать 2 одноимённых приложения в рамках одного Apache-процесса (как разные виртуальные хосты) возникал конфликт. А именно: - нельзя было вести боевую и тестовую версии приложения на 1 Apache; - нельзя было вести несколько параллельных инсталляций с базными БД на 1 Apache; - нельзя было использовать разные версии ядра Zanas.pm для разных приложений. Приходилось либо использовать паллиативные средства (вроде -- о-госсподи -- mod_cgi), либо менять имя пакета вручную. Кроме того, -секцию httpd.conf приходилось засорять некоторыми побочными в сущности командами, а также включать директории приложений в глобальный @INC, что тоже сильно отдаёт помойкой. Теперь всё будет по-другому. Появился модуль Zanas::Loader, использование которого является загрузкой Zanas-приложения. Выглядит это так: use Zanas::Loader '/var/projects/my_app/lib/MY_APP' => 'MY_APP_PRODUCTION' , { db_dsn => "DBI:mysql:database=my_app", db_user => '...', db_password => '...', core_load_modules => 1, core_spy_modules => 1, core_gzip => 1, # core_path => '/old/crap/zanas-engine', }; В результате будет создан пакет MY_APP_PRODUCTION, загруженный из /var/projects/my_app/lib/MY_APP. Соответственно, обработчики должны устанавливаться директивами SetHandler perl-script PerlHandler MY_APP_PRODUCTION и PerlModule больше не нужны. (Точнее, не будут работать, поскольку 'use lib' следует убрать). Модули MY_APP.pm тоже становятся атавизмами. Итак, самое радостное: теперь никто не мешает загрузить тот же самый (или другой) MY_APP под именнем MY_APP_PRODUCTION_2 или MY_APP_TEST с совсем другим $preconf в рамках соседнего VirtualHost'a. Естественно, MY_APP можно грузить и в MY_APP -- это даже будет работать чуть быстрее. Кстати говоря, стоит иметь в виду, что при загрузке MY_APP в MY_APP_PRODUCTION все посдстроки 'MY_APP' в исходниках прикладной части будут заменяться на 'MY_APP_PRODUCTION'. Это сделано во-первых из-за календаря, а во-вторых для совместимости с приложениями, которые используют require_fresh внутри себя. То есть, если вдруг вы назовёте исходный пакет, скажем, 'S' -- с SQL будут проблемы. Ещё одна приятность: если кто считает последний релиз Zanas.pm нестабильным, то он может указать источник загрузки ядра опцией core_path. Естественно, сам Zanas::Loader при этом должен присутствовать в @INC, но не опасайтесь: сам по себе он ничего не импортирует. Ещё кое-что поменялось по мелочи. Например, содержимое страницы с типом _info: пути загрузки вынесены в отдельный столбец, печатается путь для Zanas.pm, детские шалости с именами версий ушли в прошлое. В статику добавлены favicon.ico и robots.txt. И в очередной раз изменён алгоритм определния того, что данный запрос -- на статику (теперь напрямую проверяются известные имена файлов в $r -> uri). Если же, паче чаяния, статика не доехала, то, по крайней мере, осиротевший onkeydown не должен мешать нажимать на клавиши (проверяется, определена ли typeAheadInfo).