CMF на перле

[2NetFly]

Занимаюсь разработкой сбжа на основе MVC model 2 с использованием паттернов front controller, application controller, template view и пр. Сравнить можно с maypole (perl), OpenInteract (perl), php-mvc (php), WACT (php), Struts (Java). Реализация бизнес логики и логики представления может быть произвольная, сам использую самописные классы для модели (аналог Class::DBI) и TT2 для view.

Концепция более или менее продумана, есть упрощенная реализация в черновом варианте. Дополнительно написан механизм валидации (аналог WACT-ского). В результате хочу получить что-то более прозрачное и простое, чем OpenInteract, более функциональное и правильное (с точки зрения ООП), чем maypole и содержащее некоторые хорошие идеи из Struts.

Пишу в свободное от работы время, один не то что бы не справляюсь, просто некоторые спорные моменты обсудить не с кем, зачастую очень много времени уходит на то, чтобы увидеть очевидные для других вещи. Если кто-то занимается решением подобной задачи, было бы интересно поделиться опытом или, что еще лучше, заняться разработкой совместного решения.

[2NetFly]

Эм, неужели никто таким не занимается? Или я отстал от жизни и у всех есть готовые системы? =)

[NeoNox]

2NetFly:
Эм, неужели никто таким не занимается?

Вероятно нет. С удовольствием почитал http://maypole.perl.org/, нашел спорные моменты, но еще не готов ввязываться в дискуссию.
Ты бы написал краткий обзор своего виденья CMF, может и единомышленники нашлись.

[2NetFly]

Maypole, имхо, лучший perl MVC фреймворк. Впрочем, это неудивительно, учитывая то, кто его писал и поддерживает =)

Лично мне в нем не нравится специфический perl-ООП стиль написания, концентрация всей логики в одном классе, тесная интеграция с Class::DBI, отсутствие встроенного механизма валидации и многие мелочи.

Касательно моего виденья CMF - ничего революционного и новаторского в нем нет. Просто после написания и использования нескольких собственных неудачных систем, изучения литературы по данной теме, а так же изучения существующих решений, у меня сформировалось собственное мнение и виденье реализации, воплощением в жизнь которой и я занимаюсь. Вечером я постараюсь в двух словах рассказать, как я представляю себе CMF.

[2NetFly]

Появилось свободное время, посему постараюсь описать в двух словах CMF так, как вижу ее я.

Как я уже писал выше, CMF разрабатывается на основе MVC model 2 паттерна, что подразумевает выделение трех слоев: модели, представления и контроллера. Реализация модели т.е. бизнес логики может быть произвольная т.к. доменные объекты должны быть отделены от преставления и контроллера. CMF не должна накладывать никаких ограничений на реализацию преставления: может использоваться как один из шаблонизаторов типа Template Toolkit или HTML::Template, embeded-технология вроде Mason, так и xml + xlst.

Для реализации контроллера применятся паттерн Front Controller, который состоит из самого обработчика и команд. Для маппинга (связи между url и соответствующими командами) используется глобальный для всего проекта xml-конфигурационный файл. Пример (упрощен для понимания):




Все запросы проходят через контроллер (я для этих целей использую mod_rewrite), который выполняет следующие действия:
1. Считывает глобальный для всего проекта конфигурационный файл.
2. Создает экземпляры объектов классов Request, Displayer, Response, Context.
3. Используя методы созданных классов, парсит запрос и определяет table и action, сохраняет параметры post, get и т.д.
4. Парсит xml конфигурационный файл и на основе table и action находит информацию о соответствующем классе-команде.
5. Создает экземпляр объекта класса-команды и вызывает методы execute созданного объекта. Класс-команда может создавать и манипулировать доменными объектами, регистрировать данные, которые будут доступные во View и т.д. Класс-команда посредством специального метода должен определить, какой  view будет работать после его завершения.
6. Управление передается объекту класса Displayer, который, на основе данных установленных командой, получает нужные шаблоны, процессит их и пишет результат в Response.
7. Выводит данные пользователю.

Response похож по функциональности на соответствующий класс в Struts и php-mvc. Displayer является аналогом класса View в maypole и путем наследования и добавления функциональности может быть "прикручен" к любому шаблонизатору.

Помимо всего этого частью системы нужно сделать:
1. Механизм валидации параметров и вывода пользовательских ошибок. Я уже сделал подобный механизм на основе правил.
2. Хранилище сообщений и языковых настроек и поддержка многоязычности.
3. CRUD класс, который будет базовым для всех простых классов модели.
4. Набор common классов-команд таких как Add, Delete, Create, View, с возможностью конфигурирования посредством xml-конифга.

И много-много мелочей, вроде системы обработки ошибок, логирования и пр.

Многое из описанного выше уже готово и если кто-нибудь захочет принять участие в разработке, с радостью покажу код - это будет лучшим описанием.

[2NetFly]

Решил поднять тему. Ни у кого не возникло желания поучаствовать? =) Как я уже писал выше, лучшей помощью будет участие в обсуждении тех или иных вопросов, связанных с системой.

[NeoNox]

2NetFly уважаю твое стремление.
Можно тебя попросить обрисовать сферу использования Maypole? Также, расскажи пожалуйста про степень уверенности в 100% корректности и лишенности мемори-ликов кода сопутствующих модулей.
Спасибо.

[2NetFly]

Насчет сферы использования Maypole я ничего сказать не могу - я эту систему в серьезных проектах не использовал. Поставил, покопался в коде, перечитал всю документацию и статьи на Perl.com, но ничего серьезного не делал. Хотя, я думаю, что как и все MVC CMF она может быть использована практически в любом серьезном веб-приложении. На предыдущей версии своей системы, которая была очень далека от идеала, у меня были написаны стандартный портал с новостями, статьями, фотогалереей и пр., приличный mp3 архив и музыкальная энциклопедия и несколько биллинговых систем различного уровня сложности.

Я несколько месяцев уделил изучению различных систем на разных языках и всевозможных книг / статей по данному вопросу и на этот раз хочу сделать все правильно и надолго =) Помимо стандартных фич хочу включить в систему:
- механизм валидации пользовательских данных (параметров);
- механизм хранения и отображения сообщений об ошибках, с поддержкой многоязычности;
- CRUD класс, реализующий ORM для простой таблицы;
- DBAL на основе DBI;

[2NetFly]

Вот небольшой пример маппинга одного действия (очень упрощенный):

<actions>
    <action table="user"
            name="reg"
            className="Reg"
            classPath="module/User/class"
            successAlias="..."
            failedAlias="..."
            failedValidateAlias="..."
            >
        <validate>
            <rule group="login" name="Regexp">
                <fields>
                    <field>login</field>
                </fields>
                <params>
                    <param>^\\w+$</param>
                </params>
            </rule>

            <rule group="password" name="Regexp">
                <fields>
                    <field>password</field>
                </fields>
                <params>
                    <param>^\\w+$</param>
                </params>
            </rule>
            
            <rule group="email" name="Email">
                <fields>
                    <field>email</field>
                </fields>
            </rule>

            <rule group="password" name="Compare">
                <fields>
                    <field>password</field>
                    <field>repassword</field>
                </fields>
            </rule>

        </validate>
        
        <messages>
            <message type="COMPARE_FAILED" group="password">user.password_ne_repassword</message>
            <message type="REGEXP_FAILED" group="password">user.password_invalid</message>
            <message type="REGEXP_FAILED" group="login">user.login_invalid</message>
            <message type="EMAIL_FAILED" group="email">user.email_invalid</message>
        </messages>
        
        <templates>
          <template id="add">document_add.tmp</template>
        </templates>
    </action>
</actions>

[2NetFly]

На самом деле XML - это обертка для класса валидатора, при необходимости проверка может быть реализована в самом классе обработчике. Но это все так, частные случаи.

[Макс]

2NetFly:
2. Создает экземпляры объектов классов Request, Displayer, Response, Context.

а что делает объект Context ? (можно просто ссылкой)

2NetFly:
- механизм валидации пользовательских данных (параметров);
......
 - CRUD класс, реализующий ORM для простой таблицы;

То есть валидация и CRUD-операции не будут находиться в одном (доменном) классе ?

PS

2NetFly:
Я несколько месяцев уделил изучению различных систем на разных языках и всевозможных книг / статей по данному вопросу и на этот раз хочу сделать все правильно и надолго =)

Ruby on Rails смотрел ? Если смотрел, то интересно твое мнение.

[2NetFly]

а что делает объект Context ? (можно просто ссылкой)

Это контейнер (возможно, лучше было бы его именно так назвать) для других объектов плюс в нем собраны методы, которым я не нашел места в других классах. Проще всего объяснить кодом:

my $c = WCP::Context->new();
$c->{displayer} = WCP::Displayer::TT->new();
$c->{config} = WCP::Config::Base->new();
$c->{response} = WCP::Response->new();
$c->{request} = WCP::Request::CGI->new;
my $fc = WCP::FC->new();
$fc->process($c);

То есть валидация и CRUD-операции не будут находиться в одном (доменном) классе ?

Я планирую сделать валидацию параметров, полученных от пользователя, отдельным этапом (как в Struts). Т.е. сначала выполняется метод validate класса-команды и лишь затем, в случае успеха, execute. Т.е. при передаче параметров в доменный класс, последний знает, что параметры гарантировано проверены. С точки зрения безопасности это не лучшее решение, но зато очень гибкое. Механизм валидации почти такой же, как в WACT. Вот пример (то что под оберткой):

sub validate
{
    my ($self, $c) = @_;
    
    my $validator = WCP::Validator->new();
    my $md = WCP::Validator::MessageDictionary->new();
    
    $validator->addRule(\'title\', \'title\', \'Length\', [3, 10]);
    # То же самое, что $validator->addRule(\'title\', \'title\', WCP::Validator::Rule::Length->new(3, 10));
    $validator->addRule(\'title\', \'title\', \'Regexp\', [ \'^[a-zA-Z ]+\' ]);
    $validator->addRule(\'categoryid\', \'categoryid\', \'Regexp\', [ \'^\\d+$\' ]);
    $validator->addRule(\'type\', \'type\', \'Regexp\', [ \'^\\d+$\' ]);
    
    $md->registerMessage(\'Недопустимые символы.\', \'REGEXP_FAILED\');
    $md->registerMessage(\'Слишком короткий.\', \'LENGTH_MIN\');
    $md->registerMessage(\'Слишком длинный.\', \'LENGTH_MAX\');
    
    my %params = $c->request->getParams();
    if ($validator->validate(\\%params)) {
        return 1;
    } else {
        $c->setErrors($validator->getMessageList($md));
        return;
    }
} 

Принцип работы прост: при регистрации правила первым параметром указывается имя поля (или ссылка на массив имен полей), которые участвуют в проверке, вторым - имя группы, а третьим и четвертым - имя класса и параметры для конструктора. Правило имеет метод validate, которое возвращает булево значение. Если валидация не удалась, посредством метода getCodes можно получить массив констант, обозначающих неудавшиеся проверки (например, LENGTH_MIN, LENGTH_MAX и т.д.). После регистрации произвольного числа правил и валидации, в случае возникновения ошибок для каждой группы сохраняется массив (в порядке, указанном при регистрации правил) кодов ошибок. Грубо говоря:

Код: [Выделить]


{
    \'title\' => [
          \'LENGTH_MIN\',
          \'REGEXP_FAILED\'
     ],
     \'categoryid\' => [
          \'REGEXP_FAILED\'
     ]
 };

Потом в словарь сообщений добавляются тексты: или общий для каждого типа ошибки (например, для REGEXP_FAILED "Недопустимые символы") или для каждого типа ошибки и группы (например для title + REGEXP_FAILED "Поле title содержит недопустимые символы").

Отображение выполняется при помощи следующего шаблона:

[% INCLUDE header.tpl title="Добавление документа"%]

[% BLOCK field %]
  [% IF errors.${fld_name} %]
    <tr><td>
    <div class="error_str">[% errors.${fld_name}.0 %]</div>
    </td></tr>
  [% END %]     
    <tr><td>
  [% IF errors.${fld_name} %]<div class="error_fld">[% fld_title %]:</div>
  [% ELSE %][% fld_title %]:[% END %]
    </td>
[% END %]

<form method="post" action="[% base %]/document/adddo">
  <table>

[% INCLUDE field 
  fld_name = "title"
  fld_title = "Название"
%]     
    
      <td>
        <input type="text" name="title" value="[% param.title | html %]">
      </td>
    </tr>
[% INCLUDE field 
  fld_name = "categoryid"
  fld_title = "Категория"
%]     
      <td>
        <input type="text" name="categoryid" value="[% param.categoryid | html %]">
      </td>
    </tr>
[% INCLUDE field 
  fld_name = "type"
  fld_title = "Тип"
%]     
      <td>
        <input type="text" name="type" value="[% param.type | html %]">
      </td>
    </tr>
    <tr>
    <td><input type="submit"></td>
    </tr>
  </table>
</form>

Т.е. если при заполнении какого-то поля были допущены ошибки, поле выделяется цветом, а под ним пишется текст первой ошибки (или можно вывести список всех ошибок сразу же).

Все немного сумбурно, т.ч. если будут какие-то конкретные вопросы - спрашивайте. По валидатору у меня есть документация, немного доработаю и выложу.

[2NetFly]

Решил выложить на обозрение весь механизм валидации.

По правилам оформил небольшой обзор:
Документация по правилам
Но правила - это только основа всего механизма. Остальное продокументирую потом, а пока можно скачать архив и посмотреть на реализацию. Код довольно чистый, я вложил пример т.ч. все должно быть понятно. Имейте в виду, что это черновой вариант =) Работа с сообщениями и MessageDictionary точно будут перерабатываться.

[2NetFly]

Повесил блог, писать буду там, а комментировать можно здесь.

Блог: http://2netfly.com/blog/ .

[2NetFly]

Отписал довольно много аналитики, сумбурно, конечно, но общие принципы уже уловить можно.