Записки программиста. Cms perl
Краткий обзор качества коммерческой CMS на Perl / Хабр
Мораль же будет такова — доверяй, но проверяй.
PS. Мне в руки попала версия 10. Текущей является версия 11.
habr.com
Perl CMS : гигантомания или слишком умные?
Решил на досуге посмотреть какие-нибудь интересные open source CMS на perl.. посмотрел и очень удивился почти полным отсутствием таковых, тогда как на PHP они плодятся пачкам и каждый день. Похоже Movable Type - это самое достойное из движков расчитанных на небольшие/средние сайты (он же и под mod_perl работает если нужно), но он и не совсем уж и бесплатный (ограниченная лицензия). Ну а из прочих все какие-то мастодонты встречаются, которые позиционируют себя как "content management system and an application framework 2 in 1":- WebGUI http://www.plainblack.com/spreadwebguiдовольно много к нему аддон-ов ,плагинов. Расчитан на работу под mod_perl. Но мне что-то он не очень понравился по архитектуре, хотя лишь слегка покопался в его внутренностях.- Bricolage http://www.bricolage.cc/ модная тема в последнее время в perl сообществе.. Что-то его активно продвигают, хотя вещь в себе, которую еще делать и делать. "CMS корпоративного уровня".. угу. Этот проект принимает участие в гуглевском Summer of Code..и судя по тому, что к нему еще нужно привинтить, так он "under constraction" ( подробнее тут ) (а ниже я про него еще одну забавную штуку напишу).Использует шаблонизаторы: Mason, Template Toolkit, или HTML::Template.Статья на Perl.com: Content Management with Bricolage
- Krang http://krang.sourceforge.net/ то, что как говорят авторы "выросло" из неудобоваримости Bricolage. В состав разработчиков входят весьма уважаемые перлисты (среди них Sam Tregar - автор HTML::Template, Class-XPath-1.4, XML::Validator::Schema и т.д.,Jesse Erlbaum автор замечательного модуля CGI::Application). Тоже "немаленький" проектик с минималистичным интерфейсом, но довольно прикольной архитектурой. Тоже заточен под mod_perl, есть rpm пакеты для удобства установки). Меня повеселили данные, сравнивающие Krang и Bricolage (по воз-тям и производительности), "вот самая суть":
The following table compares a few common operations on Bricolage and Krang system with approximately 7,000 stories, running on identical machines (Redhat Linux 7.3, dual P4-2Ghz, 4GB of ram, with their databases tuned appropriately).
| Operation | Krangv1.011 | Bricolagev1.4.6 |
| Single Story Publish | 0.33 seconds | 4 seconds |
| Total Site Publish | 38 minutes | 6.5 hours |
| Story Find by Title | 0.15 seconds | 2 seconds |
7000 статей + они делают вывод в XML+ много авторов и категорий, но 6,5 часов для всего это дела ИМХО как-то не але (и все это под mod_perl)Кстати, если интересно, тут можно увидеть произ-ть Kranga при различной нагрузке. Шаблонизатор HTML::Template.. не знаю, мне кажется что для подобного проекта учитывая его ООП было бы интересно использовать что-то "понавороченее", типа Template-Toolkit.
К чему я все это? Возможно я плохо искал, но что-то ничего толкового, "земного" не нашел. Стоит ли пытаться соединить CMS и Framework в одном? Получается кастрированный и ограниченный Framework и "перекаченный" и намудренный, CMS.
О Framework.. Недавно прочитал статью о Catalyst ( http://www.perl.com/pub/a/2005/06/02/catalyst.html ) пример в статье ИМХО несколько бестолковый, но сама эта штука меня заинтересовала, весьма приятно смотрится внутри :) MVC:Model: Class::DBI, Plucene, Net::LDAP (ну вот не очень мне нравится Class::DBI - c виду и поначалу хорош, но там многое надо довинчивать + тормоза при больших выборках.)View: Template Toolkit, Mason, HTML::TemplateController: свои каталистические замутки.
Сайт проекта: http://catalyst.perl.org/ с документацией пока не але (про примеры молчу), но может разродятся, он сейчас весьма активно развивается. Да... Maypole загнулся, OpenInteract в свободном плавании (ранее разработка спонсировалась), печальна жизнь open sourca ,если нет рядом заинтересованного спонсора, на энтузиазме далеко и надолго не уедешь ..
P.S. во я накатал!
green-kakadu.livejournal.com
Определение CMS средствами Perl | Записки программиста
Недавно написал несколько скриптов, позволяющих автоматически определять, какая CMS (Content Management System, система управления контентом) используется на сайте. Вот решил выложить на всеобщее обозрение.
В архиве вы найдете четыре скрипта, каждый для своей CMS — Drupal, Joomla, WordPress и TextPattern. Рассмотрю устройство одного из них, поскольку все работают по одному принципу.
# iswp.pl script# (c) Alexandr A Alexeev 2009 | http://eax.me/
use strict;
my $dn = shift;
print "Invalid domain name\n" and exit 1 unless($dn =~ /^[a-z0-9\.\-]+$/);
my $data = `wget -q $dn -O -`;
print "Download failed: $?\n" and exit 2 if($?);
my $cnt = 0;
$cnt ++ if($data =~ /UTF\-8/gi);$cnt ++ if($data =~ /\/wp\-content\/themes\//gi);$cnt ++ if($data =~ /\/wp\-content\/plugins\//gi);$cnt ++ if($data =~ /WordPress/gi);$cnt ++ if($data =~ /\/wp\-includes\//);$cnt ++ if($data =~ /\/xmlrpc\.php/);
$cnt = int $cnt * 100 / 6;
print "WordPress:$cnt\n";
Как видите, все очень просто — скрипт принимает в качества аргумента доменное имя, обращается к соответствующему сайту с помощью wget, затем ищет в HTML-коде сигнатуры WordPress’а. Чем больше сигнатур найдено, тем больше вероятность, что данный сайт работает на WordPress.
Я писал скрипты так, что если найдено больше половины сигнатур (вероятность больше 50%), можно быть почти уверенными, что CMS опознана. Так что выводимое скриптом число не следует воспринимать чисто как вероятность.
Можно увеличить точность определения, если для каждого сайта вызывать каждый скрипт. Например, если для какого-то сайта iswp.pl вернул 50%, а isdrupal.pl и остальные вернули 30% или меньше, значит мы точно имеем дело с WordPress. Если же несколько скриптов вернули большое (больше 50%) значение, значит CMS не опознана.
Приведенные скрипты имеют несколько существенных, на мой взгляд, недостатков. Во-первых, и это не сложно исправить, HTML-код не кэшируется. Это может создать большие проблемы при массовом определении движков. Что, если мне захочется узнать статистику используемых CMS, скажем, по всему рунету?
Во-вторых, мы не определяем версию CMS. В ряде случаев это не сложно сделать, например WordPress вставляет в HTML-код соответствующий meta-тег:
<meta name="generator" content="WordPress 2.8.5" />
Другие CMS часто пишут свою версию в подвале (footer) страницы. Но на мой взгляд, это — задача уже других скриптов, которые следует использовать уже после того, как CMS была определена.
В-третьих, мы производим анализ сайта только по одной, главной странице. Встречаются сайты, главная страница которых просто содержит приветственное сообщение, на них с помощью моих скриптов ничего обнаружить не удастся. На сайте может быть использовано несколько CMS. Кроме того, анализ нескольких страниц мог бы существенно увеличить точность определения. Например, наличие каталога /wp-admin/ явно свидетельствует об использовании WordPress (да, это моя любимая CMS, потому ее название так часто встречается в тексте).
В настоящее время я подумываю начать работу над новой серией скриптов. В них я добавлю кэширование HTML-кода и автоматический сбор сигнатур. Последнее позволит существенно увеличить число определяемых движков. Кроме того, проверке будет подвергаться не доменное имя, а конкретный URL. Если быть точнее, код конкретной страницы, потому что скрипты будут читать его через STDIN, из кэша.
Дополнение: Нашел в сети сервис автоматического определения CMS, может кому-нибудь пригодится: http://2ip.ru/cms/. Кстати, на этом сайте вообще много интересных скриптов.
Дополнение: Продолжение эпопеи об определении CMS — Автоматическое определение движка форума.
Метки: Perl.
eax.me
