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

Пример работы:

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

user:
 id:
 login:
   type: varchar(64)
   required: true
   index: unique
 password:
   type: varchar(40)
   required: true
 first_name:
   type: varchar(64)
   required: true
 last_name:
   type: varchar(64)
   required: true
 email:
   type: varchar(128)
   required: true
   index: unique

...

Сразу хочу предупредить - в качестве ORM’а использовался Propel, для Doctrine схема будет несколько иная, но очень похожая.

Создадим для этой модели форму регистрации по адресу account/register. Для этого создадим модуль account и в его actions.class.php добавим следующий код:

public function executeRegister() {
  if($this->getRequest()->getMethod() === sfRequest::POST) {
    $user = new User();
    $user->setLogin($this->getRequestParameter('login'));
    $user->setPassword($this->getRequestParameter('password'));
    $user->setFirstName($this->getRequestParameter('first_name'));
    $user->setLastName($this->getRequestParameter('last_name'));
    $user->setEmail($this->getRequestParameter('email'));
    $user->save();
    $this->redirect('main/index');
  }
}

Для этого метода создадим шаблон registerSuccess.php примерно следующего содержания:

<?php use_helper('Validation') ?>

<?php echo form_tag('account/register') ?>

<fieldset>

<div>
<?php echo label_for('login', 'Логин'); ?>
<?php echo input_tag('login', $sf_params->get('login'), array('class' => 'text')); ?>
<?php echo form_error('login'); ?>
</div>

<div>
<?php echo label_for('password', 'Пароль'); ?>
<?php echo input_password_tag('password', null, array('class' => 'text')); ?>
<?php echo form_error('password'); ?>
</div>

<div>
<?php echo label_for('password_repeat', 'Подтверждение пароля'); ?>
<?php echo input_password_tag('password_repeat', null, array('class' => 'text')); ?>
<?php echo form_error('password_repeat'); ?>
</div>

<div>
<?php echo label_for('first_name', 'Фамилия'); ?>
<?php echo input_tag('first_name', $sf_params->get('first_name'), array('class' => 'text')); ?>
<?php echo form_error('first_name'); ?>
</div>

<div>
<?php echo label_for('last_name', 'Имя'); ?>
<?php echo input_tag('last_name', $sf_params->get('last_name'), array('class' => 'text')); ?>
<?php echo form_error('last_name'); ?>
</div>

<div>
<?php echo label_for('email', 'E-mail'); ?>
<?php echo input_tag('email', $sf_params->get('email'), array('class' => 'text')); ?>
<?php echo form_error('email'); ?>
</div>

</fieldset>

<div class="submit">
<?php echo submit_tag('Зарегистрироваться') ?>
</div>
</form>

Всё, регистрация уже работает и вы вполне можете заходить по адресу account/register вводить данные и нажимать кнопку “Зарегистрироваться”. Одна проблема - никаких ограничений на вводимые данные нет. Давайте это исправим.

С этого момента в дело вступают валидаторы. Создадим директорию validate в модуле и добавим туда register.yml следующего содержания:

fields:
  login:
    required:
      msg: Логин не может быть пустым
    sfPropelUniqueValidator:
      class: User
      column: login
      unique_error: Уже существует пользователь с таким логином
  password:
    required:
      msg: Пароль не может быть пустым
  password_repeat:
    required:
      msg: Пароль не может быть пустым
    sfCompareValidator:
      check: password
      compare_error: Пароли не совпадают
  email:
    required:
      msg: E-mail не может быть пустым
    sfEmailValidator:
      strict: true
      email_error: Неправильный формат e-mail'а
    sfPropelUniqueValidator:
      class: User
      column: email
      unique_error: Уже существует пользователь с таким e-mail
  first_name:
    required:
      msg: Введите свою фамилию
  last_name:
    required:
      msg: Введите своё имя

С этого момента все входные данные будут проверятся на валидность. Как можно видеть - для каждого поля формы указываются отдельные валидаторы. Перечислим используемые здесь:

• required - показывает, что поле не должно быть пустым, аттрибут msg содержит тот текст, который будет выведен при вызове в шаблоне функции form_error с переданным в качестве аргумента названием поля (см. registerSuccess.php выше)
• sfPropelUniqueValidator - проверяет, существуют ли в указанной таблице еще записи, содержащие введенное значение в указанном домене
• sfCompareValidator - сравнивает текущее поле с полем, указанным в параметре check
• sfEmailValidator - ну, тут, я думаю, всё понятно

Теперь хочется сказать, что если все входные данные не пройдут валидацию, то вместо метода executeRegister будет вызван метод handleErrorRegister из того же класса, если такой существует. В данном случае я хочу, чтобы пользователя переадресовывало на ту же страницу (чтобы пользователь мог увидеть ошибки, которые он допустил при вводе данных). Для этого я добавлю в класс простой метод handleErrorRegister следующего вида:

public function handleErrorRegister() {
  return sfView::SUCCESS;
}

Теперь даже если данные не пройдут валидацию - всё равно будет отображена та же страничка.

Выводы

В плюсы можно занести следующее:

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

К минусам можно отнести:

• Отсутствие динамически генерируемых форм (т.е. пишем класс формы, с определенными полями и навешиваем на них валидаторы, сразу же в этом классе, а потом просто создаем обьект класса и выводим его/осуществляем валидацию)
• Соответственно, нет никаких связей между моделями и формами

Плюсы хороши. Но минусы расстраивают, особенно при наличии таких замечательных моделей. Так что… читайте следующую статью, которая будет после последнего экзамена, 25-го числа, в которой я расскажу про новый Form Framework, разработанный для Symfony 1.1.

PS. Я тут так подумал… Стоит ли писать про стандартные функции Symfony подробнее? Например, для тех, кто не знаком с этим фреймворком фраза “создадим модуль account” выглядит не совсем понятно. Стоит ли расписывать, как это нужно делать, или всё же лучше писать как сейчас, т.к. ответы на такие вопросы есть в онлайн книге?..

PPS. Ну всё… Теперь я на 3 дня с головой ушел в подготовку к последнему экзамену.

Но сейчас я хотел бы поговорить не об этом… Есть одна “маленькая”  идея - затеять сравнение фреймворков друг с другом. По каким критериям сравнивать - вопрос довольно сложный, я составил следующий список:

• Controller
• Model
• View
• наличие/удобство хелперов
• взаимодействие с JS/AJAX
• работа с формами (сейчас с этим в Symfony, кстати, достаточно большие проблемы)
• …

Пунктов, я думаю, с вашей помощью добавится еще с десяток. Так что жду предложений.

Следующий вопрос - список фреймворков. Опять же, мой список пока что состоит из таких претендентов:

• Kohana (или всё же CodeIgniter)
• CakePHP
• Symfony
• Zend Framework
• …

Писать хочу в виде “один пост рассматривает все фреймворки по одному критерию”. Т.е., например, через две недели будет опубликовано сравнение моделей в выбранных фреймворках - возможности, удобства, недостатки, пожелания относительно улучшения и т.д.

Теперь я подошел к самому главному - хотелось бы попробовать устроить действительно коллективную работу… Никто не хочет помочь мне в этом деле? Я вот лично могу на себя взять Symfony и (хотя и не хочется) Kohana. Никто не хочет написать про CakePHP или про <вставьте сюда название вашего любимого фреймворка>? На каждый пост будет отводится, скажем, неделя-две. После этого кто-то (думаю я, если кто-то захочет помочь - пишите) скомпонует все посты в одно сравнение, сделает выводы…

Первым критерием для сравнения предлагаю сделать Controller и всё что с ним связано (routes, dispatchers  и т.д.). Если меня кто-то поддержит - жду ваши тексты до 1-го февраля. И 3-го будет первый пост по сравнению фреймворков.

В обоих статьях больше всего (как мне показалось), хвалили Symfony. Также мне приглянулись Zend Framework (от разработчиков PHP) и Prado (.NET-подобный фреймворк, ориентированный на обработку event’ов).

Symphony

Наверное, один из лучших фреймворков для PHP (блин, надоело, далее будет просто “пхп”), построенный на принципах ROR (о нем я уже чуть-чуть писал). Он использует сторонние разработки (Propel для ORM, Creole для работы с БД и т.д.), “объединяя” их в одно целое. Здесь действительно есть очень многое, НО, по-моему, фреймворк ОЧЕНЬ сложен для новичков. Прочитав начало их документации (end-user которая), стало понятно, что МНЕ такое использовать либо еще рановато, либо вообще не стоит. Скорее всего второе :)

Prado

Общение с фреймворком закончилось после прочтения документации. Задумка хорошая (как я узнал позже, она сюда перекочевала из asp.net), но меня она не устроила в принципе. Мне ото фреймворка нужно было немного другое (да, каюсь, с MVC-паттерном я знаком лишь очень отдаленно, никогда его не использовал и узнал о нем, собственно, из блога SM.org).

Zend Framework

Фреймворк от разработчиков пхп. Как мне кажется, в него комманда зенда решила вложить то, чего не хватало самому языку пхп, правда в некоторых моментах они перестарались (сделайте Zend::dump() от строки с русскими буквами в юникоде), но все же пользоваться фреймворком, как по мне, вполне удобно. Он содержит много разных вещей, с помощью которых можно делать многие вещи гораздо удобнее. Им я сейчас и пользуюсь.

Кстати, заметил за собой такую “штуку” - вот сделал что-то с этим фреймворком, теперь мне как-то без него неуютно… Что посоветуете/скажете по этому поводу?

Сейчас зенд находится в стадии beta. Многие вещи еще будут переделываться (особенно это касается тех вещей, которые сейчас находятся в incubator’е), но им УЖЕ можно пользоваться и он РЕАЛЬНО помогает.
Чего не то, чтобы не хватает, а что хотелось бы увидеть в этом фреймворке - так это ORM, потому как сейчас ее нет даже в инкубаторе, а жаль.

Я думаю, я еще вернусь к этой теме.