У нас работает новый грузчик. Его зовут Фазекс.

В этот раз мы коснулись проблемы, которую не рассматривали очень давно. Речь идёт о механизме загрузки 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), либо менять имя пакета вручную.

Кроме того, <perl>-секцию httpd.conf приходилось засорять некоторыми побочными в сущности командами, а также включать директории приложений в глобальный @INC, что тоже сильно отдаёт помойкой.

Теперь всё будет по-другому. Появился модуль Zanas::Loader, использование которого является загрузкой Zanas-приложения. Выглядит это так:

<perl>

	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',

	};  
	

</perl>

В результате будет создан пакет MY_APP_PRODUCTION, загруженный из /var/projects/my_app/lib/MY_APP. Соответственно, обработчики должны устанавливаться директивами 

<Location />
   SetHandler  perl-script
   PerlHandler MY_APP_PRODUCTION
</Location>

и 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).