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

Сейчас для меня самый главный вопрос - что именно делать. Есть варианты:

• Блог - нужен, скорее всего, будет только мне, да и… сколько людей уже строило свои блоги… я, конечно, могу быть одним из них, но… в общем, если других вариантов не будет - возьмусь за блог
• Простенькую социальную сеть. Даже не знаю, на какую тему, и что там вообще должно быть…
• Может, что-нибудь еще… Хочу адекватные по сложности (и по времени разработки!) варианты услышать от вас. Что бы вы хотели, или что бы мне, на ваш взгляд, могло бы быть наиболее полезно.

Пока же - вот здесь выложены видеозаписи выступлений с конференции (не все, но посмотреть есть на что). Выступления, как по мне, очень интересные. Особенно (естественно!) хочется отметить выступление о моей любимой Symfony.

PS. Что-то не везет мне с ноутами. Заказал у знакомых HP Compaq 6720s. Обещали привезти сегодня до 12-ти из Киева. Приезжаю в час в магазин - “машина Автолюкса (служба доставки) сломалась по дороге, ноута пока нет”. 

Сегодня мы займемся установкой Symfony на ваш компьютер. Первым делом идем на офсайт и смотрим страницу, описывающую процесс установки! Несмотря на наличие этой страницы, мне всё же задают вопросы - “как ставить”, “какой способ установки выбрать” - судя по всему, такая статья лишней не будет.

Существует 3 основных способа установки Symfony на ваш компьютер:

1. Скачать архив
2. Установить из SVN
3. Установить через PEAR

Установка путем скачивания архива

Скачиваем архив (symfony 1.1 beta 2) с официального сайта, и распаковываем в любую директорию (не обязательно в php’шный include_path). После чего фреймворком уже можно пользоваться. Но есть неудобства - для того, чтобы пользоваться консольными командами - прийдется каждый раз прописывать в консоли путь к файлу “symfony.bat” (или “symfony”, в зависимости от того - пользуетесь вы ОС на основе *nix или Windows), этот файл находится в ./data/bin. Для того, чтобы убрать этот недостаток:

• под Windows - пропишите путь к “symfony.bat” в переменную PATH (помочь вам сделать это может Google).
• под *nix - запустите “sudo ln -s /<путь к директории, куда вы распаковали архив>/data/bin/symfony /usr/bin/symfony”

После этого можете пользоваться в консоли командами типа “symfony init-project” и т.д.

Плюсы: простота - кроме скачивания и распаковывания архива ничего не нужно делать; если на компьютере, на который вы собираетесь устанавливать Symfony, нет интернета - достаточно просто принести архив на этот компьютер.

Минусы: отсутствие автоматизации - для обновления Symfony прийдется самостоятельно повторять процедуру.

Установка из SVN

Если вы не знакомы с SVN - лучше выберите первый вариант. Процедуру прописывания путей к ./data/bin/symfony прийдется повторять и здесь. Для установки - перейдите в директорию, куда хотите установить symfony и введите:

svn checkout http://svn.symfony-project.com/branches/1.1

в *nix-ОС, либо проделайте подобную процедуру (checkout) через TortoiseSVN под Windows - объяснять не буду - у TortoiseSVN интуитивно-понятный интерфейс.

Плюсы: можно удобно обновляться до самой последней версии с помощью возможностей SVN; если на компьютере, на который вы собираетесь устанавливать Symfony, нет интернета - достаточно просто принести директорию, куда вы “установили” Symfony на этот компьютер.

Минусы: в SVN может находится не совсем стабильная версия (стабильные версии хранятся в http://svn.symfony-project.com/tags/); способ сложнее для тех, кто не умеет работать с SVN.

Установка через PEAR

Если у вас не установлен PEAR - тогда вам пора обратится к Google.

Установка очень проста (перевод доки с офсайта):

Введите в коммандной строке:

$ pear channel-discover pear.symfony-project.com

Для установки стабильного релиза (на данный момент это 1.0.12), введите:

$ pear install symfony/symfony

Для установки бета-версии (на данный момент - 1.1 beta 2, т.е. то, что нам нужно), введите:

$ pear install symfony/symfony-beta

Для обновления Symfony воспользуйтесь следующими командами:

$ pear upgrade symfony/symfony

или

$ pear upgrade symfony/symfony-beta

Плюсы: очень простая установка, а также отсутствие производить махинации с переменной PATH/символическими ссылками; очень удобное и простое обновление.

Минусы: проблемы с установкой на компьютерах без интернета (я не зря это пишу, такие вопросы уже были).

Есть и еще один способ:

Установка sandbox’а

Sandbox - это “пустое” приложение Symfony вместе с самим фреймворком. Скачать его можно отсюда. Архив распаковываем (!!!) в директорию сервера, например: localhost у вас настроен на директорию c:\www\. Вы распаковали архив в директорию c:\www\test\ таким образом, что директория web у вас содержится в c:\www\test\web\. После этого запускаем сервер и заходим на адрес http://localhost/test/web/ и видим начальную страничку, сгенерированную Symfony.

Я сам в случае с Symfony 1.1 воспользуюсь именно sandbox’ом.

Ссылки:

• У Макса появилась отличнейшая статья о том, что сейчас наблюдается в рунете с блогами с SMO. Знать бы, как с этим бороться…
• Тем, кто использует Propel в Symfony -появился отличный плагин, упрощающий написание запросов через Criteria - sfPropelFinder.

В Symfony 1.1, в отличии от предыдущей версии, полностью изменилась работа с формами (а также еще очень многими вещами, которых, я надеюсь, я коснусь позже) - вместо кучи кода, разбросанного по многим местам (которым, впрочем, вполне удобно пользоваться благодаря достаточно удобным view helper‘ам) появилось достаточно красиво спроектированная ОО-система, собирающая логику работы с формами в одном месте.

На That’s Quality не зря назвали серию постов “Forms, Widgets and Validators” - работа с формами предполагает знания именно об этих трех компонентах, которые объединены под общим названием Form Framework:

• Forms - компонент отвечает за логику работы формы, не зацикливаясь на её внешнем виде.
• Widgets - собственно, классы, представляющие собой графические элементы формы. Здесь определяется то, как форма будет выглядеть внешне.
• Validators - компонент, отвечающий за проверку правильности введенных значений в форму.

На самом деле, насколько я понял из кода Symfony, эти три компонента всё же довольно сильно связаны между собой и вряд ли вам захочется использовать каждый из них по отдельности, но в общем они составляют довольно целостную структуру.

Как же это с этим всем великолепием работать, спросите вы? Ответы будут в следующих статьях, а пока же просто приведу пример использования формы.

Создаем саму форму в контроллере:

class userActions extends sfActions
{
  public function executeIndex()
  {
    $this->form = new RegisterForm();
  }
}

И выводим её во View:

<form method="post" action="<?php echo url_for('user/index') ?>">

<table cellspacing="0" cellpadding="0">
  <?php echo $form ?>
</table>

<div class="submit">
  <input type="submit" value="Submit" />
</div>

</form>

Что это еще за RegisterForm? Узнаете завтра, а пока что советую вспомнить, о чем я писал в статье про формы в Symfony 1.0. Вспомнили? Теперь стало понятно название RegisterForm?

В общем, посмотрим… Завтра посмотрим.

PS. Сегодня, кстати, вышла вторая бета-версия Symfony 1.1, на которой я и буду тестировать всё, что я напишу. Список изменений по сравнению с Symfony 1.0 лежит здесь - достаточно занимательное чтиво.

1. Я вообще считаю, что пишу не слишком интересно (по сравнению с людьми, блоги которых я читаю), но реакция на некоторые мои посты говорит совершенно иное, и я этому очень рад.
2. Статья, ИМХО, удалась. И, судя по отзывам, многие вполне не прочь прочитать что-нибудь еще по этой теме. Хотя, если честно, я рассчитывал на иной результат - многим (особенно в рунете) кажется, что Symfony слишком тормознутая и сложная, и что тратить время на её изучение совершенно не стоит, ведь есть всякие CodeIgniter‘ы и прочее. Оказалось, всё не совсем так, и еще есть люди, которые думают иначе (а есть и такие, которые стали думать иначе после моей статьи)… И я этому очень рад.
3. В рунете очень мало ресурсов по Symfony… И мне хочется немного заполнить эту нишу. Да, уже есть перевод книги по Symfony (хоть и не полный) на русский язык, но этого мало. В рунете не хватает простых “туториалов” - как делать то или иное, с какой стороны подходить к этому фреймворку, пошаговых примеров разработки приложений (типа 24-хдневного guide’а по построению Askeet)… С одной стороны - я не сильно люблю писать тексты для чайников (либо переводить зарубежные), но с другой - мне, в принципе, не сложно, а если другим будет от этого польза - то я буду только рад. Стоит ли мне писать что-то подобное?

Да и вообще - хочется услышать ваши пожелания относительно того - о чем стоит писать в пределах глобальной темы - фреймворка Symfony.

PS. Писать часто буду вряд ли - времени нет особо… Но я стараюсь выделять своему блогу время. :) 

PPS. Пост про Symfony 1.1 Form Framework будет… Очень надеюсь, что на этой неделе…

PPPS. Писать на Хабрахабр интересные статьи очень выгодно:

Вообще, я люблю проектировать, продумывать, анализировать те или иные решения, которые хочу внедрить в систему (хотя, признаюсь, опыта у меня в этом маловато), но как обьяснить заказчику, что ты провел день в раздумьях… Эх…

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

Собственно, всё начинается с создания проекта (project) и приложений (applications) в нем. Как это делается — можно почитать в книжке (ссылка приведена выше), а мне бы хотелось остановиться на обьяснении того, что такое проект и принципах выбора приложений в нем — какие им дать имена, как их структурировать и т.д.

Проект

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

Приложения

В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.

Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).

Сам я пользуюсь рекомендацией книги и имею два приложения в своем проекте.

Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.

Окружения (environments)

Останавливаться на окружениях особенно не хочется. Это очень удобный, но в то же время очень простой механизм, обеспечивающий возможность заходить в одно и то же приложение с различными серверными настройками. Если сказать проще — представьте себе, что у вас есть приложения и галочка, которая переключает режим его работы в debug-mode и обратно. В debug-mode, например, все события логгируются, все ошибки выводятся на экран и т.д. Если же debug-mode выключен — все логи выключены, и на экране никогда никаких ошибок появляться не будет. Так вот — в Symfony вместо флага debug/не-debug имеется просто несколько различных окружений, каждое из которых можно настроить ПОЛНОСТЬЮ, т. е. не система решает — что включить, а что выключить, а вы сами. Хочется также отметить, что особо копаться в настройках вам не прийдется — по умолчанию для каждого приложения создается 3 environment’а: production, development, testing (используется исключительно при тестировании).

В общем, тут придраться не к чему — всё, на мой взгляд, просто идеально.

Модули (modules)

… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.

Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.

Последнее, на чем хотелось бы остановиться — это…

Модели (models)

Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за 3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно.

Пожалуй, это всё, что может понадобиться новичку при изучении Symfony (чтобы она не казалась ему какой-то сложной и непонятной системой, какой она мне показалась год назад).

А вот теперь перейдем непосредственно к моим рекомендациям. Но перед этим я расскажу вам про…

Плагины (plugins)

Плагины — это, по сути, тот код, который может быть использован несколько раз в разных проектах и приложениях. Плагины могут содержать:

• конфигурационные файлы, в том числе свои модели (!!!)
• модули
• библиотеки

Я могу оказаться не прав, но как мне кажется, плагины — это такие себе мини-проекты, «всё в себе», чем выгодно отличаются от Symfony applications. На мой взгляд, ставку стоило делать в первую очередь на них — убрать приложения, а вместо них поставить плагины и создать некий инструмент, который бы позволил эти плагины связывать между собой.

Мои рекоммендации

• В первую очередь — проектирование. Не скупитесь на этом шаге, анализируйте и уточняйте у заказчика непонятные пункты.
• Видя перед собой (да хоть в уме) макет системы — продумайте, на какие части систему можно разбить.
• Поищите среди существующих плагинов такие части (обязательно). Я в своем проекте использовал следующие плагины:
  • sfGuardPlugin — user management, security и т.д. Плагин - must have.
  • sfDateTimePlugin — очень удобная работа с датами и временем
  • sfPropelAlternativeSchemaPlugin — полезен при работе с плагинами, позволяет менять модели, прописанные в плагинах, не изменяя коды самих плагинов
  • sfPropelApprovableBehaviorPlugin — мне очень пригодился при «активации пользователей»
  • sfThumbnailPlugin — уменьшение картинок (не смотрите на название — с ресайзом 3MP-фотографий к 800×600 плагин справляется на отлично)
  • sfPropelActAsTaggableBehaviorPlugin — если вам нужны тэги
  • sfPropelActAsSluggableBehaviorPlugin — если вам нужны slug’и (а я советую их использовать — очень хорошо сказывается на читаемости url’ов, когда вместо id туда засовывать slug’и)
  • sfPropelActAsRatableBehaviorPlugin — рейтинги, довольно крутые, мне, к сожалению, не подошли…
  • sfPropelActAsCommentableBehaviorPlugin — всё, что нужно для комментариев
• Используйте в работе автоматически генерируемые CRUD-модули и модули для админки

Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.

Давно у меня таких больших статей не было…

Запостил на Хабрахабр.

• Отличная серия постов по Symfony 1.1 Form Framework
• Блог по Symfony (официальный или нет, хз). Была интересна статья про Symfony IDE. Теперь я пользуюсь Eclipse + Symfoclipse.
• Русскоязычное сообщество Symfony (на мой взгляд, если у вас с английским более-менее нормально, сюда лучше вообще не ходить - нифига интересного).
• Книгу по Symfony на русском лучше всего читать здесь (есть несколько переводов, как я понял, один из них на вышеприведенном сайте, но тут - самый полный).

И напоследок: мне недавно нужен был перевод из русского UTF-8 на латиницу в PHP. Ддо этого я его делал так: считываем по символу (или по нескольку символов) из строки и строим новую строку транслитерированием. Из плюсов - быстро, из минусов - напрягает выбирать по нескольку букв. Потом мне предложили использовать str_replace. Из плюсов - быстро пишется. К сожалению, долго работает. Есть и еще один вариант:

function rus_to_translit($string)
{
  $converter = array(
    'а' => 'a',  'б' => 'b',  'в' => 'v',   'г' => 'g',  'д' => 'd', 'е' => 'e', 'ё' => 'e', 'ж' => 'zh',
    'з' => 'z',  'и' => 'i',  'й' => 'y',   'к' => 'k',  'л' => 'l', 'м' => 'm', 'н' => 'n', 'о' => 'o',
    'п' => 'p',  'р' => 'r',  'с' => 's',   'т' => 't',  'у' => 'u', 'ф' => 'f', 'х' => 'h', 'ц' => 'c',
    'ч' => 'ch', 'ш' => 'sh', 'щ' => 'sch', 'ь' => '\'', 'ы' => 'y', 'ъ' => '',  'э' => 'e', 'ю' => 'yu',
    'я' => 'ya',
    'А' => 'A',  'Б' => 'B',  'В' => 'V',   'Г' => 'G',  'Д' => 'D', 'Е' => 'E', 'Ё' => 'E', 'Ж' => 'ZH',
    'З' => 'Z',  'И' => 'I',  'Й' => 'Y',   'К' => 'K',  'Л' => 'L', 'М' => 'M', 'Н' => 'N', 'О' => 'O',
    'П' => 'P',  'Р' => 'R',  'С' => 'S',   'Т' => 'T',  'У' => 'U', 'Ф' => 'F', 'Х' => 'H', 'Ц' => 'C',
    'Ч' => 'CH', 'Ш' => 'SH', 'Щ' => 'SCH', 'Ь' => '\'', 'Ы' => 'Y', 'Ъ' => '',  'Э' => 'E', 'Ю' => 'YU',
    'Я' => 'YA',
  );

  return strtr($string, $converter);
}

При этом не забудьте файл, в который вы это пишете сохранить в кодировке UTF-8. ИМХО, оптимальный вариант.

PS. Не забудьте сегодня поздравить свои половинки с днем всех влюбленных!

Первое, о чем хочется сказать - очень удобно реализованы связи one-to-many. Propel сама сгенерирует базовые классы, в которых такие связи будут учитываться изначально. Пользоваться очень удобно, своего кода в моделях приходится писать очень мало, а если быть более точным - почти весь код в данном случае получается именно product-specific. В случае со связями one-to-one проблемы появляются - как я этого ни добивался, Propel упрямо считает эти связи такими же, как и one-to-many и генерирует неправильный код. Исправляется обычно дописыванием правильных функций вручную, благо, обычно дописать только get<PrimaryKey>-функции. В моем случае я вообще перестроил БД так, что таких связей у меня не оказалось, так что конкретного ничего сказать не могу.

Второе - “всё - обьекты”. Очень популярное в ООП высказывание подходит к Propel’у просто замечательно. Работа с Propel’ом заключается исключительно в работе с обьектами-записями и обьектами-таблицами. Никаких php’шных массивов (привет CI и CakePHP), одни классы и обьекты. Очень удобно. С эффективностью, правда, могут возникать огромные проблемы. Я, кстати, так до сих пор и не знаю, как эффективно выбрать (категория + количество продуктов в ней) за один запрос. Но беспокоиться об этом я буду уже потом.

Блин, вот сидишь на работе и думаешь - сколько всего можно написать, плохого и хорошего, а приходишь домой и нифига не вспоминается.

Третье - many-to-many. После того, как у меня появились такие связи, я начал очень сильно жалеть о том, что я не выбрал Doctrine… По сравнению с ней (она дополнительную many-to-many таблицу создает сама и сама же за ней следит) в Propel’е всё ужасно - приходится создавать вручную таблицы и дописывать в них целую кучу кода, который бы вполне могла дописать сама библиотека в базовых классах. Может в том же CI это вполне нормальным кажется (контраст другой), но здесь, когда строишь модель базы данных - мыслишь исключительно в обьектах, которые тебе будут нужны. И добавлять (а еще сопровождать) эту [непонятно откуда взявшуюся, в реале-то её нет] таблицу очень неудобно.

Четвертое - опять по сравнению с Doctrine’ой - нет возможности “опускаться” на уровень SQL не теряя ORM’а. Т.е. либо Propel ORM, либо Creole (PDO). В Doctrine’е есть для таких случаев DQL - достаточно удобная штучка, если поглядеть по мануалу. Вообще, Doctrine, на мой взгляд, гораздо более функциональная, мощная и удобная библиотека. Да и User Guide’ы у неё гораздо более полные и, как ни странно, user-friendly.

Но по сравнению со всем остальным, что я видел на PHP - Propel - это очень круто.

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

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

Предположим, что существует следующая модель пользователя (здесь и далее все конфигурационные файлы будут пприводится в формате 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 дня с головой ушел в подготовку к последнему экзамену.