Вот что я нарыл... CMS на Perl!!!!!!
1) Ядро движка.
Собственно, ядро состоит из двух (пока) библиотек - API и ADI.
С первой всё ясно уже из названия - это главная функциональная
библиотека, всё основные функции хранятся там. Вторая либа
предоставляет админ-API-функции (ADministrative Interface) -
используется главным образом для построения
админ-интерфейсов к модулям и взаимодействию с главным
admin-модулем движка. На самом деле ADI базируется на API, и
эту библиотеку нельзя считать самостоятельной - скорее, это
как надстройка над API.
2) Модульная расширяемость возможностей.
Вообщем-то, стандарт дефакто в современных CMS, и удивляться
тут нечему. В нашем случае, модули вызываются ядром движка
(ну, не совсем так, но сойдёт
). При этом модули могут
использовать все функции API не вызывая конструктор движка.
Т.е. мы как-бы импортируем функции модуля в ядро движка и
пользуемся ими, как внутренними. Также возможно использование
функций других (ранее загруженных) модулей. В целях экономии
памяти, модули грузятся избирательно - только те, которые
необходимы на данной странице (Хотя можно грузить и все
каждый раз, достаточно указать initMods => 1 в описании вызова
конструктора API). Также возможно использование модулей
расширения возможностей самого движка - в этом случае
можно как добавлять новые функции в ядро, так и перезаписывать
старые функции новыми.
3) Возможность ПОЛНОЙ смены дизайна (вот она, вкусность).
Возможности языка perl позволяют использовать
шаблонизированный вывод, благодаря regexp-выражениям
(изюминка perl), чем я и воспользовался. XEN позволяет
настроить себя под любой дизайн (мы ведь не говорим о
таком отстое, как фреймы, правда ? ;)). При этом вэбмастеру
не нужно разгребать бешенные кучи из смеси кода и HTML,
как это есть в PHPNuke. Зачем вэбмастеру быть
web-программистом, если он вэбмастер, и это не входит
в его компетенцию ? Вот и я о том же....
4) Использование СУБД.
Конечно, это тоже не является новинкой - сейчас все современные
и уважающие себя CMS используют различные СУБД для
хранения данных. Вот и я решил, что все данные должны
храниться в БД - ведь это в с одной стороны удобно для
разработчика, а с другой стороны это удобно и для владельца
сайта, ведь этим обеспечиватся огромная гибкость -
дистрибутив CMS можно переставить и не нужно
рыть и вытаскивать какие-то файлы с данными из
дистрибутива. Все данные можно на крайний случай
вытащить из БД в один файл. В XEN я использовал СУБД
MySQL (по слухам, mSQL тоже прокатит ;)).
Почему именно они ? Потому что MySQL быстрая, надежная
и некоммерческая СУБД, которая использутся большинством
хостеров. А ещё, потому что я другие незнаю... ;))
5) Безопасность.
Этому я уделяю особое внимание, так как дырявый движок
никому не нужен (особенно мне
). Особое внимание я уделяю
таким багам, как возможные SQL-Injection. Include баги совсем
не наблюдаются, да и я редко где встречал Include-баги в perl -
это прерогатива PHP
. Хотя, криворукие кодеры на всё
способны
. Доступ к коммандной строке нереален (невозможен
не могу сказать - всё возможно
), т.к. единственные операции
с файлами - это чтение шаблонов (причём права доступа явно
указаны, как и месторасположение шаблонов).
6) Скорость и размеры.
Я думаю, что ни для кого не будет секретом, что perl работает в
разы быстрее, чем PHP (Тихо-тихо ! Не кричите так громко !
Это уже доказано
) А если ещё и через mod_perl или FastCGI
- то вообще супер !
О размерах... Сейчас XEN (v0.5.6-dev)
в tar.bz2 архиве весит ~80 Кб. Ну как ?