Ну и вот мы делаем такой финт ушами:

modules:
  class: sfDoctrineRouteCollection
  options:
    model:                modules
    module:               modules
    prefix_path:          /modules
    column:               module_id
    with_wildcard_routes: true
    object_actions:       { action1: GET, action2: GET }
  requirements:
    module_id:        \d+

В сгенеренный роут я добавил параметр object_action, после чего этот роут будет так же генерить роуты @modules_action1 и @modules_action2, что нам собственно и нужно. А GET - это тип запроса, на который будет отзываться новоделанный роут.

Как, наверное, некоторые из вас знают, 8 октября прошла конференция Symfony Day 2010 в Кёльне, на которой мне посчастливилось присутствовать. Я случайно наткнулся на сайт, http://www.symfonyday.com/, и сразу же решил, что хочу туда. Вход стоил 120 евро, но я успел как early bird за 80. Путь мой начинался с самой восточной границы Германии, и лежал почти до западной, более 550 километров, причем ночью. Не хотелось тратиться на гостиницу, а тут еще подвернулся вариант с CNL (ночным) поездом, я думал, что это вроде плацкартного. Как выяснилось, место у меня сидячее, в купе едут по 6 человек, спать было почти невозможно. Так что приехал я в Кёльн за 3 часа до конференции весьма измотанный.

На входе в медиа-центре Komed, где происходило действие, красовались флаги Symfony Day. Нам выдали беджики, и мы пошли в зал. Было еще рано, поэтому народу почти не было, зато на экране запустили Twitterwall - прямую трансляцию из Твиттера по хештегу #sfdaycgn, сделанную с помощью node.js. Я не преминул возможностью передать привет всем присутствующим от друзей из Russian Symfony User Group .

Первым выступал Jonathan Wage, который рассказал о работе Doctrine 2 с Mongo DB. Он вкратце обьяснил что же за зверь такой этот Mongo DB, и привел примеры, как с помощью Doctrine делать самые обычные действия - прочитать/вставить/удалить. Доклад был интересным, однако слушал я с трудом. Сказалась ночь в поезде и меня жутко клонило в сон. Не припомню когда я еще проявлял столько воли, чтобы не засыпать и не зевать. Сразу после я побежал заливаться кофе, а вы пока можете посмотреть слайды.

Вторым выступал core developer PHP Pierre Joye. Этот доклад был наполнен юмором. Если доклад Джонатана был вроде утренних новостей, то доклад Пьера как первая развлекательная передача дня. Рассказ был о том, как развивается PHP, какие есть недостатки, и что с этим можно делать. В зале нашелся человек, который до сих пор пользуется PHP4. Угадайте, какую CMF он использует? Правильно, Drupal. А вот вам цитатка:"A lot of idiots use PHP. For example.. (slide) Microsoft". Главным слайдом презентации можно считать "PHP is ugly". Да, разработчик PHP признает, что язык уродлив. Но мы же не художники в конце концов. Нам не о красоте надо думать, а о том, как создавать проекты, которые будут успешно работать. К тому же, если использовать Symfony, то недостатки заметны меньше. Да и помимо Symfony написано достаточно хороших фреймворков, и вряд ли есть большой спрос на новые. "Кто вообще писал новый фреймворк за последние два года",- вопрошал Пьер. Руку поднял один человек в зале - Фабьен Потенсьер Все засмеялись и заапплодировали. Важной мыслью было то, что PHP уже достиг того когда он почти никогда не является "бутылочным горлышком". "Если вам не хватает производительности PHP - то вы Facebook".

Пока был перерыв перед следующим докладом - я сделал фотографию зала. По количеству стульев можно прикинуть, что было человек 150. А выступал третьим Christian Schaefer (Кристиан Шефер), симфони-блоггер. Может я ошибаюсь, но мне показалось, что у него не очень большой опыт подобного рода выступлений - в основном он повторял то, что было написано на слайдах. Тем не менее, слушать было интересно. А речь шла о Unit-тестировании плагинов с помощью PHPUnit. О том, как все правильно настроить, и как тесты запускать.

После третьего доклада был перерыв, и в холле можно было было вкусно покушать. А я же в первую очередь побежал делать эту фотографию. Так же в перерыве познакомились и немного поболтали с Антоном Бобенко, сам он из Украины, работает в Норвегии. Не знаю, был ли кто-нибудь еще из русскоязычных.

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

Следующим выступал Гейлорд Олке (Gaylord Aulke). Этот доклад был, я думаю, не столько для программистов, сколько для работников отдела продаж. Гейлорд рассказал о том, как представить клиенту выбор, покупать готовый сайт, который можно просто запустить, или заказывать разработку, которая займет время, но зато проект будет соответствовать пожеланиям клиента. Есть еще третий вариант - построить проект из модулей.

Последним выступал Фабьен Потенсьер. Речь шла о Symfony2, которая должна быть готова к марту 2011. Во-первых, для темплейтов можно будет использовать шаблонизатор Twig. И хотя поддержка чистого PHP останется, Twig гораздо более прост для восприятия и использования непрограммистом. Пользователь, как объект, теперь не привязан к сессии, пользовательские данные можно будет хранить в конфиг-файле (например, если нужен только один админ), можно будет одновременно аутентифицировать пользователей через БД, LDAP и конфиг файлы. Формы можно будет показывать с помощью темплейтов, того же твига. В общем масса изменений, все будет супер-круто. Ну и приложу слайд, который будет во всех блогах и отчетах про конференцию

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

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

Для эксперимента еще выложил фотографии на flickr.

Сразу оговорюсь, речь опять пойдет о плагине. Всю функциональность проекта я стараюсь реализовывать в плагинах, если есть хоть малейший намек на то, что это может потребоваться где-то еще. В конкретном случае модуль для статических страниц (в схеме: заголовок, текст, слаг, метаполя). И вот важный момент, для плагинов можно создать файл PLUGINNAMEConfiguration.class.php. Нам это пригодится тем, что мы будем создавать роуты на лету, начиная как раз с этого файла.

Обычно я убираю названия плагинов/модулей из листингов, но в данном случае ради наглядности и простоты понимания я их оставлю. Плагин называется wePages, модуль wePages_frontend. И вот значит что мы будем делать в конфигурации:

public function initialize() {
  if (in_array('wePages_frontend', sfConfig::get('sf_enabled_modules', array()))) {
    $this->dispatcher->connect('routing.load_configuration', array('wePagesRouting', 'listenToRoutingLoadConfigurationEvent'));
  }
}

Если наш модуль числится в списке подключенных, то подключаем listener по имени listenToRoutingLoadConfigurationEvent из файла wePagesRouting к событию routing.load_configuration. Проще говоря, когда загрузится конфигурация роутов будет вызвана наша функция.

Создадим файл /lib/routing/wePagesRouting.class.php, куда поместим нашу функцию.

class wePagesRouting {
 
  /**
   * Listens to the routing.load_configuration event.
   *
   * @param sfEvent An sfEvent instance
   * @static
   */
  static public function listenToRoutingLoadConfigurationEvent(sfEvent $event) {
    $r = $event->getSubject();
 
    // Узнаем максимальную глубину дерева
    $maxlvl = Doctrine_Query::create()->
              select('MAX(level) as maxlvl')->
              from('wePages')-> 
              execute()->
              getFirst()->
              getMaxlvl();
 
    // В конфигурации мы можем указать префикс для роута, 
    // например '/page', начинаться же он должен со слеша, 
    // что мы и проверяем
    // prefix must have '/' 
    if (trim(sfConfig::get('app_we_pages_plugin_route_prefix', ''))) {
      $route_pattern = '/'.trim( sfConfig::get('app_we_pages_plugin_route_prefix', ''), '/');
    } else {
      $route_pattern = '';
    }
 
    // Здесь мы создаем строчку, на соответствие которой в роутинге 
    // будет проверятся URL, тут-то и кроется вся магия. 
    // Мы создаем роут с количеством слагов равным максимальной 
    // глубине дерева, чтобы охватить все страницы, а в качестве 
    // значения по умолчанию ставим false, чтобы роут срабатывал 
    // и на меньшем количестве слагов
    $defaults = array();
    for ($i = 0; $i <= $maxlvl; $i++) {
      $route_pattern .= '/:slug'.$i;
      $defaults['slug'.$i] = false;
    }
 
    // осталось теперь только подключить роут к уже загруженным, 
    // важно чтобы он был первым
    // preprend our routes
    $route = new wePagesRoute(
        $route_pattern, 
        array_merge( 
            array( 'module' => 'wePages_frontend', 'action' => 'show' ), 
            $defaults 
        )
    );
    $r->prependRoute('wePages_frontend', $route);
  }
 
}

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

Обратите внимание, что мы создали объет не sfRoute, а wePagesRoute. Этот класс лежит в соседнем файле wePagesRoute.class.php. Нам ведь надо проверять довольно специфические условия, поэтому стандартный класс не подходит.

class wePagesRoute extends sfRoute {
  // функция проверяет подходит ли данный роут под указанный URL
  public function matchesUrl($url, $context = array()) {
    // если шаблон роута не совпадает - дальше даже не смотрим
    if (false === $parameters = parent::matchesUrl( rtrim($url, '/') , $context)) {
      return false;
    }
    // преобразуем наши сгенерированные слаги в массив, 
    // где ключи - это глубина элемента в дереве,
    // а значения - сами слаги.
    // почему так? у нас же рекурсивный роут и начинается 
    // с верхнего уровня, который имеет level = 0
    // соответственно следующие слаги имеют level = 1,2,3..
    // make slug1, slug2.. into array [0] => 'slug1', [1] => 'slug2'
    $i = 0;
    $pages = array();
    while (isset($parameters['slug'.$i]) && strlen(trim($parameters['slug'.$i]))) {
      $pages[$i] = $parameters['slug'.$i];
      $i++;
    }
 
    // если выяснилось, что слагов не указано - бросаем это дело
    // If we dont have any slugs - we dont want this anymore
    if (empty ($pages)) {
      return false;
    }
    // Второй важный момент
    // Мы берем слаги и уровни, и ищем страницы подходящие под условия. 
    // Данный способ не работает, если slug не уникальны.
    // Groupby объединяет элементы с одинаковым уровнем
    // Get pages with these slugs and levels
    $data = Doctrine_Query::create()
        ->from('wePages')
        ->andWhereIn('slug', array_values($pages))
        ->andWhereIn('level', array_keys($pages))
        ->orderBy('level ASC, lft ASC')
        // this group by removes entries with same level
        ->groupBy('level')
        ->execute();
 
    // теперь внимательно смотрим, если нашли страниц меньше, 
    // чем было указано слагов то URL не совпадает с иерархией в БД, 
    // а значит, извините, но вы не по адресу.
    // искали 3 слага - надо найти 3 страницы, и чтобы их level 
    // были равны 0,1,2 и не повторялись
    // проблемы начнутся, если слаги могут совпадать, 
    // но другого быстрого и простого способа проверить я не придумал
    // If some url parts dont fit - dont want this anymore
    if (count($data) < count($pages)) {
      return false;
    }
 
    // если мы не указали в конфигурации префикс 
    // и страницы вызываются, как www.site.com/page1
    // то этот роут будет выполнятся довольно часто, 
    // поэтому раз уж мы выполнили поиск страниц
    // было бы глупо не передать уже найденный id в метод show,
    // или что там у вас для показа
    $parameters['page_id'] = $data->getLast()->getId();
 
    return $parameters;
  }

У меня этот метод прекрасно заработал, хотя и не является идеальным решением. Если я хочу создать страницы /team/men, /team/women, то мне придется создавать и страницу /team, и она будет открываться, хотя я, например, хотел бы чтобы она редиректила на /team/men. То есть надо было бы создавать тип страниц "редирект". Что порядком костыльно. Так же, вероятно, будут проблемы с link_to и url_for. Стоит написать свой хелпер для генерации урлов.

Что еще можно сделать? Можно при создании страницы указывать URL напрямую, и хранить его в БД. И точно так же в роуте проверять не соответствие слагов и уровней, а просто искать по полю url. Позволяет обойти проблему с /team/men, хотя и не очень красиво, страница /team, будет выдавать 404. Хотя как я понимаю, проблему с link_to оно все равно не решит.

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

public function  setupInheritance() {
    parent::setupInheritance();
 
    $this->widgetSchema['parent'] = new sfWidgetFormDoctrineChoiceNestedSet(array(
        'model' => 'MODEL_NAME',
        'add_empty' => true
    ));
    $this->validatorSchema['parent'] = new sfValidatorDoctrineChoice(array(
        'model' => 'MODEL_NAME', 
        'required' => false
    ));
}

Добавили виджет и валидатор. sfWidgetFormDoctrineChoiceNestedSet это простой DoctrineChoice, в котором есть отступы и сортировка в соответствии с иерархией в NestedSet. Теперь наш виджет виден в форме, правда ни на что пока не влияет.

Чтобы на что-то влиять, нам надо добавить его в список полей фильтра в том же файле.

public function getFields() {
    $fields = parent::getFields();
    $fields['parent'] = 'NestedNode';
 
    return $fields;
}

Здесь надо обратить внимание не только на значение, но и на имя ключа в массиве. В качестве значения можно указывать "Number", "Text", "Date" и некоторые другие. Я не пробовал, но полагаю, что если указать одно из них, то сработает стандартный обработчик поля фильтра, как например addNumberQuery. В нашем случае формат нестандартный и обработчик будем делать сами.

Кстати говоря, если в данный момент посмотреть на наш проект - нам выбросят исключение, где будет сказано как надо назвать метод, который будет обрабатывать наше поле. В моем случае это addParentColumnQuery. Формат названия функции, скорее всего такой: add_COLUMN_NAME_ColumnQuery.
А собственно вот и она сама:

public function addParentColumnQuery($q, $element, $value) {
    $parent = Doctrine::getTable('MODEL_NAME')->findOneById($value);
    return $q->andWhere('lft > ?', $parent->getLft())->andWhere('rgt < ?', $parent->getRgt());
}

Получаем Doctrine_Query в качестве параметра $q, добавляем свои условия и возвращаем. Все легко и просто.

Наздоровье
Референс: http://robert-says.com/2010/03/symfony-how-to-add-a-custom-filter-for-the-admin-listing/

$query->addWhere('level = ?', 0);

Это потому, что все, что ниже уровнем мы будем получать через getChildren. Иначе нам пришлось бы двигать итератор Doctrine_Collection, что более сложно, заумно, и вовсе у меня не получилось (next($objects) почему-то не дает эффекта).
Сделать optgroup в choice совсем несложно, надо лишь сделать элемент массивом. Ну а что получилось собственно внутри поста.

Я еще раз повторюсь, что это код sfWidgetFormDoctrineChoiceNestedSet, за малым изменением.

class weDoctineOptgroupSelectWidget extends sfWidgetFormDoctrineChoice {
 
  public function getChoices() {
    $choices = array();
    if (false !== $this->getOption('add_empty')) {
      $choices[''] = true === $this->getOption('add_empty') ? '' : $this->getOption('add_empty');
    }
 
    if (null === $this->getOption('table_method')) {
      $query = null === $this->getOption('query') ? Doctrine_Core::getTable($this->getOption('model'))->createQuery() : $this->getOption('query');
      // force manual sorting according to root_id then by lft
      $query->addOrderBy('root_id asc')
          ->addOrderBy('lft asc');
      // Viktoras: we need to fetch only top level, as we'll get the children with getChildren()
      $query->addWhere('level = ?', 0);
      $objects = $query->execute();
    } else {
      $tableMethod = $this->getOption('table_method');
      $results = Doctrine_Core::getTable($this->getOption('model'))->$tableMethod();
 
      if ($results instanceof Doctrine_Query) {
        $objects = $results->execute();
      } else if ($results instanceof Doctrine_Collection) {
        $objects = $results;
      } else if ($results instanceof Doctrine_Record) {
        $objects = new Doctrine_Collection($this->getOption('model'));
        $objects[] = $results;
      } else {
        $objects = array();
      }
    }
 
    $method = $this->getOption('method');
    $keyMethod = $this->getOption('key_method');
 
    foreach ($objects as $object) {
      // indent item by 4 spaces per level
      // Viktoras: here we check for children and make entry an array if they exists
      $node = $object->getNode();
      if ($node->hasChildren()) {
        foreach ($node->getChildren() as $child) {
          $choices[$object->$method()][$child->$keyMethod()] = str_repeat(' ', ($child['level'] * 4)) . $child->$method();
        }
      } else {
        $choices[$object->$keyMethod()] = str_repeat(' ', ($object['level'] * 4)) . $object->$method();
      }
 
    }
    return $choices;
  }
 
}

И выглядит это вот так:

Как вообще убрать фильтры в admin generator?

config:
  filter:
    class: false

Как повесить иконку своему кастомному object_action?

#sf_admin_container ul li.sf_admin_action_##ACTION_NAME## a
{
  background: url(/images/icons/icon.png) no-repeat 0 0;
}

Как недопустить ввода пустой строки в админке?

public function configure() {
    $this->validatorSchema['name']->setOption('trim', true);
}

Fatal error: Call to undefined function include_component()
Вы, скорее всего, указали в settings.yml standart_helpers, и забыли добавить в список Partial.

all: 
  .settings: 
    standard_helpers:       [I18N, Partial]

Некоторые люди утверждают, что Symfony - это подарок богов. Другие считают, что это преувеличение. Но как ни крути, в версиях 1.3/1.4 добавилось много нового и полезного, что может сэкономить вам вермя.
Представим проект, где есть разные заметки (новости, интервью, и т.д.). И они могут быть на разных языках. И это довольно просто сделать с actAs: I18n. Но есть небольшая сложность: переводы должны быть опциональны, чтобы можно было написать статью только на французском, английском или немецком.

Некоторые материалы по теме: раз, два, три, четыре, пять.

Итак, начнем со схемы.

Article:
  actAs:
    Timestampable: ~
    I18n:
      fields: [ title, body ]
      actAs:
        Sluggable: { fields: [ title ], uniqueBy: [ lang, title ] }
 
  columns:
    title: { type: string(255), notnull: true }
    body: { type: clob, notnull: true }
    author: { type: string(255), notnull: false }
 
News:
  inheritance:
    extends: Article
    type: concrete

А так же фикстуры:

News:
  n1:
    author: 'Lenta.ru'
    Translation:
      ru:
        title: 'Нет вестей с Титана'
        body: |
          Титан – это шестой и самый крупный спутник Сатурна.
 
  n2:
    author: 'Bash.org'
    Translation:
      en:
        title: '#921792'
        body: |
          <Thomas> if women think they arent meant to cook
          <Thomas> why do they have milk and eggs inside them?

Загружаем все это добро в базу данных:

php symfony doctrine:build --all --and-load
php symfony generate:app backend
php symfony doctrine:generate-admin backend News

Загляните в только что построенный модуль админки. Нажмите кнопку "редактировать" и оп.. а где все наши переводы? Если вы еще не в курсе, actAs:I18n разделяет таблицу на 2 части, в первой содержатся общие поля, не зависящие от перевода, а во второй те, которые требуют перевода.

mysql> SELECT * FROM news;
+----+-------------+---------------------+---------------------+
| id | author      | created_at          | updated_at          |
+----+-------------+---------------------+---------------------+
|  1 | Lenta.ru    | 2010-01-29 12:14:46 | 2010-01-29 12:14:46 | 
|  2 | Bash.org    | 2010-01-29 12:14:46 | 2010-01-29 12:14:46 | 
+----+-------------+---------------------+---------------------+
 
mysql> SELECT id, lang, title FROM news_translation;
+----+------+-----------------------------------------------------+
| id | lang | title                                               |
+----+------+-----------------------------------------------------+
|  1 | ru   | Титан – это шестой и самый крупный спутник Сатурна. | 
|  2 | en   | <Thomas> if women think they arent meant to cook ...| 
+----+------+-----------------------------------------------------+

Чтобы нам было доступно редактирование переводов - надо воспользоваться функцией embedI18n.

// lib/form/doctrine/NewsForm.class.php
class NewsForm extends BaseNewsForm
{
  /**
   * @see ArticleForm
   */
  public function configure()
  {
    parent::configure();
    $this->embedI18n(array('ru', 'en'));
  }
}

Вуа ля. Редактировать можно!

Немного приберемся

Наш код сейчас не так хорош, как мог бы быть:
Каждый раз, когда мы будем добавлять новый тип статьи - нам надо будет менять метод configure;
Каждый раз, когда мы будем добавлять/удалять новый язык для статей - нам надо будет менять все формы.

К счастью, с Symfony 1.3, наследование форм повторяет наследование моделей. Смотрите, NewsForm наследует BaseNewsForm, которая в свою очередь наследует ArticleForm.

# config/app.yml
all:
  cultures:
    enabled:
      ru: Russian
      en: English

// lib/form/doctrine/NewsForm.class.php
 
// Revert the changes we added there
class NewsForm extends BaseNewsForm
{
  /**
   * @see ArticleForm
   */
  public function configure()
  {
    parent::configure();
  }
}
 
// lib/form/doctrine/ArticleForm.class.php
class ArticleForm extends BaseArticleForm
{
  /**
   * Available languages
   *
   * @var array $languages
   **/
  protected $langages;
 
  public function configure()
  {
    $this->languages = sfConfig::get('app_cultures_enabled');
 
    $langs = array_keys($this->languages);
 
    $this->embedI18n($langs);
    foreach($this->languages as $lang => $label)
    {
      $this->widgetSchema[$lang]->setLabel($label);
    }
  }
}

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

Редактируем переводы

Давайте теперь попробуем нашу форму для статей. Когда вы попробуете редактировать какую-нибудь новость, то... постыдная неудача. Нельзя сохранить, потому что нет английского или русского перевода. Давайте добавим условие, что если в форме есть пустые поля - мы эти формы не сохраняем.
Для этого мы перекроем метод doBind.

// lib/form/doctrine/ArticleForm.class.php
class ArticleForm extends BaseArticleForm
{
  /**
   * Available languages
   *
   * @var array $languages
   **/
  protected $langages;
 
  public function configure()
  {
    $this->languages = sfConfig::get('app_cultures_enabled');
 
    $langs = array_keys($this->languages);
 
    $this->embedI18n($langs);
    foreach($this->languages as $lang => $label)
    {
      $this->widgetSchema[$lang]->setLabel($label);
    }
  }
 
  /**
   * Cleans and binds values to the current form
   *
   * Ignore i18n forms when all their fields are empty
   *
   * @see sfForm::doBind
   **/
  protected function doBind(array $values)
  {
    foreach($this->languages as $lang => $label)
    {
      if($this->embeddedI18nFormIsEmpty($values[$lang]))
      {
        unset(
          $values[$lang],
          $this[$lang]
        );
      }
    }
 
    parent::doBind($values);
  }
 
  /**
   * Check if every fields, except for id and lang, are empty
   **/
  protected function embeddedI18nFormIsEmpty(array $values)
  {
    foreach($values as $key => $value)
    {
      if(in_array($key, array('id', 'lang')))
        continue;
 
      if('' !== trim($value))
      {
        return false;
      }
    }
    return true;
  }
}

В перекрытом методе doBind, мы проверяем каждую I18n форму, и, если надо делаем ей unset. Теперь все сохраняется как надо, однако же...

Загляните в базу данных, вас там ждет сюрприз.

mysql> SELECT id, lang, slug FROM news_translation;
+----+------+------------------------------------------------------+
| id | lang | slug                                                 |
+----+------+------------------------------------------------------+
|  1 | en   |                                                      | 
|  1 | ru   | Титан – это шестой и самый крупный спутник Сатурна.  | 
|  2 | en   | <Thomas> IF women think they arent meant TO cook ... | 
+----+------+------------------------------------------------------+

Где-то в процессе сохранения, Symfony создала пустой объект перевода. И вот решение для этой проблемы.

// lib/form/doctrine/ArticleForm.class.php
 
  // Add this at the beginnig of the class:
  /**
   * I18n ignored forms
   **/
  protected $I18nFormsIgnored = array();
 
  // update the doBind method:
  /**
   * Unset i18n forms values when every field is empty
   **/
  protected function doBind(array $values)
  {
    foreach($this->languages as $lang => $label)
    {
      if($this->embeddedI18nFormIsEmpty($values[$lang]))
      {
        $this->I18nFormsIgnored[] = $lang;
        unset(
          $values[$lang],
          $this[$lang]
        );
      }
    }
 
    parent::doBind($values);
  }
 
  // And override the doUpdateObject method:
  /**
   * Updates the values of the object with the cleaned up values.
   *
   * @param  array $values An array of values
   *
   * @see sfFormDoctrine::doUpdateObject()
   */
  protected function doUpdateObject($values)
  {
    parent::doUpdateObject($values);
 
    foreach($this->I18nFormsIgnored as $lang)
    {
      unset($this->object->Translation[$lang]);
      unset($values[$lang]);
    }
  }

На этот раз все сохраняется как надо!

(Здесь я пропускаю абзац про убирание поля Slug. Там есть сложность с тем, что формы перевода не наследуются. Если вам интересно - посмотрите в оригинальной статье. Я считаю, что основное здесь - как раз перекрытие методов doBind и doUpdateObject.
Тесты, приведенные автором можно посмотреть у него в статье, а можно тут и тут).

На этом все. Надеюсь вам пригодится мой перевод.

Вообще, по правилам PEAR все инструкции написаны в README. Но там по-английски. А тут я приведу русскую инструкцию. Итак.
1. Надо или установить плагин, как PEAR пакет, или распаковать архив в папку plugins. Папка с плагином должна называться sfPropelTogglerPlugin. После этого вызовите команду symfony 'plugin:publish-assets' чтобы картинки из плагина скопировались в папку web/sfPropelTogglerPlugin. Если ничего не скопировалось - проверьте название папки плагина.
2. В settings.yml вашего приложения впишите в пункт enabled_modules: [default, sfPropelToggler]. Если вы этого не сделаете - будет выскакивать ошибка о том, что модуль не активирован.
3. В том файле, где будете подключать тогглер напишите

use_helper('Toggler');

4. Собственно сам переключатель может быть вставлен 2мя способами. Первый:

echo toggler(array('table' => 'table_name', 'field' => 'field_name', 'id' => $item->getId(), 'state' => $item->getState() ));

Где table -имя таблицы, field - поле, id - первичный ключ записи, а state - текущее состояние переключателя.
Второй способ через объект:

echo object_toggler($object, 'field_name');

Где object - объект Пропела, а field_name - поле, которе будем переключать.

На этом этапе у вас все должно заработать. Если же нет - спрашивайте в комментариях.

У меня в базе данных введен в таблице специальный столбик, называемый order_num. Он как раз и определяет порядковый номер записи в таблице. По нажатию на кнопке вверх (я называю эту процедуру promote), порядковый номер текущей записи меняется местами с порядковым ближайшим большим порядковым номером. Обратная процедура (demote) меняет с ближайшим меньшим.

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

Promote:

public function executePromote() {
$page_id = $this->getRequestParameter('page_id');
 
$connection = Propel::getConnection();
$promoting_RS = $connection->query("SELECT order_num, parent_id FROM static_pages WHERE page_id='{$page_id}'");
$promoting = $promoting_RS->fetch(PDO::FETCH_ASSOC);
$promoting_num = $promoting['order_num'];
$promoting_parent = $promoting['parent_id'];
 
if ($promoting_num < 2) {
  $this->redirect('static_pages/index');
}
$demoting_num_RS = $connection->query("SELECT MAX(order_num) AS order_num, page_id FROM static_pages WHERE parent_id='{$promoting_parent}' AND order_num < '{$promoting_num}' GROUP BY NULL");
$demoting = $demoting_num_RS->fetch(PDO::FETCH_ASSOC);
$demoting_num = $demoting['order_num'];
 
$query = "UPDATE static_pages SET order_num = CASE
   WHEN page_id = '".$page_id."' THEN '".$demoting_num."'
   WHEN parent_id='{$promoting_parent}' AND order_num='{$demoting_num}' THEN '".$promoting_num."'
   END
   WHERE page_id = ".$page_id." OR (parent_id={$promoting_parent} AND order_num={$demoting_num})";
 
$connection->query($query);
$this->redirect('static_pages/index');
return sfView::NONE;
}

Мы берем id из запроса, потом запросом ищем максимальный order_num, который меньше текущего, и потом запросом меняем их местами. Не забудьте ставить WHERE в UPDATE. На основе этого, думаю demote легко дописать самому.
P.S> Поле не должно быть UNIQUE, я так и не придумал как одним запросом менять значения между собой в UNIQUE поле.

Итак что же за переключатели такие? Допустим у нас есть сайт, а у него база данных, а в базе данных таблица, а в таблице поле, которое принимает только 2 значения - 0 и 1. Такие поля делаются типа TINYINT(1). Берем пример из жизни. Одно такое поле отвечает за то, разрешено ли пользователю входить в систему или нет. И если вдруг надо нам попереключать часть пользователей, то надо залезать в свойства каждого и менять, потом сохранять. А мне захотелось жить красивее и придумал я переключатели.

Вот так примерно выглядит список пользователей. Зеленая галочка и красный крестик и есть переключатели. Что сделать чтобы переключить пользователя? Просто кликнуть на них! По клику отправляется AJAX запрос, меняет поле в базе данных и по результатам меняет картинку. Красиво, удобно, быстро. А теперь о том, как это сделано.

Для каждого пользователя в таблице нам надо вставить партиал (partial), который будет отображать картинку. Для формирования таблицы мы foreach перебираем пользователей и вот код partial для переключателя.

<div id="active_<?php echo $user['id']; ?>">
  <?php include_partial('activity', array('id' => $user['id'], 'state' => $user['is_active']))?>
</div>

Как видно в него мы передаем 2 параметра, это id пользователя и его текущий статус. В самом партиалле находится следующий код:

<?php 
$field = 'IsActive';
?>
<div align="center" id="<?php echo $field.'_'.$id ?>">
<?php
include_component('main', 'toggler', array(
  'id' => $id,
  'table' => 'sfGuardUser',
  'state' => sfGuardUserPeer::retrieveByPK($id)->getIsActive(),
  'field' => $field
));
?>
</div>

Здесь $field - имя поля в базе данных. В партиалле создается div с названием $field_$id, куда будет присылаться ответ. Ну а дальше вызывается компонент main/toggler, который и будет собственно переключать. Компоненту мы передаем id пользователя, имя таблицы, текущее состояние и имя поля.

На этом подключение переключателя к модулю завершено. То есть вам надо всего лишь вызвать partial из шаблона, а в partiall'e подправить названия поля и таблицы. Все очень просто и быстро. Ну а собственно что в компоненте main/toggler? А там вот что:
components.class.php

public function executeToggler() {
//i just call _toggler.php partial
}

_toggler.php

<?php
$update = $field.'_'.$id;
sfApplicationConfiguration::getActive()->loadHelpers(array('Javascript'));
$image_name = intval($state)? 'active.png' : 'inactive.png';
echo link_to_remote(image_tag('/images/icons/admin/'.$image_name), array (
   'url' => 'main/toggle?id='.$id.'&table='.$table.'&field='.$field,
   'update' => $update
));
?>

Мы формируем $update - поле, куда вернем ответ. А в виде ответа мы возвращаем... переключатель. Нам надо подгрузить хелпер Javascript (обратите внимание, что надо с большой буквы писать, иначе ничего не получится. симфони требует соблюдения регистра). И с помощью хелпера генерим аяксовую ссылку на экшен, который уже и будет переключать.

Что же получается? Итак общая картинка такая. Мы подключаем partial, который вызывает компонент, который генерит шаблон выдавая нам аяксовую ссылку на действие (action). А экшен переключает нам поле, и рендерит тот же самый компонент.

public function executeToggle(sfWebRequest $request) {
  if (!$request->isXmlHttpRequest()) {
    return $this->renderText('Error. XMLHttpRequests only.');
  }
  $id = $request->getParameter('id');
  $table = $request->getParameter('table');
  $field =  $request->getParameter('field');
  $peer = $this->normalizeName($table).'Peer';
 
  $method = new ReflectionMethod($peer, 'retrieveByPK');
  $object = $method->invoke(NULL, $id);
 
  $setter = 'set'.ucfirst(strtolower($field));
  $getter = 'get'.ucfirst(strtolower($field));
 
  $object->$setter( $state = !$object->$getter() )->save();
   return $this->renderPartial('main/toggler', array('id' => $id, 'state' => $state, 'table' => $table, 'field' => $field));
}
protected function normalizeName($name) {
  $name = preg_replace('/[^a-zA-Z0-9]/', ' ', $name);
  $name = ucwords(strtolower($name));
  $name = str_replace(' ', '', $name);
  return $name;
}

Принимаем только аяксовые запросы, из запроса получаем таблицу, поле и имя Propel Peer-класса для управления таблицей. Имя таблицы мы "нормализуем", т.к. симфони не использует, например, подчеркиваний в названии Peer-классов. Ну а дальше, с помощью рефлексии мы вызываем метод для того, чтобы получить объект, над которым производим действия. Геттеры и сеттер имеют стандартные названия и их рефлексить нам не надо. После чего в ответ рендерим тот же самый компонент, который вернет нам картинку с аяксовой ссылкой на то же самое действие.

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

Почти сразу у меня возникла идея использовать input_in_place_editor. То есть табличка, в ней теги, тыкаешь на ячейку, появляется поле редактирования, изменения происходят аяксово. С самим in_place_editor возникло немало сложностей из-за его опций. Сделать табличку и насовать в каждую ячейку по эдитору несложно. Не забудьте, надо облачить это все в див, который будет обновляться. Мы же хотим показывать сохраненный тег.

Первое, с чем мне пришлось столкнуться - эффект затухания. Это очень красиво, когда наводишь на элемент, который можно редактировать, фон загорается цветом, и медленно затухает, когда уводишь мышку. Изначально фон загорается желтым, а так как админка у меня выдержана в цветах Админ-генератора, то есть синем, то и цвет надо поменять. Однако, изменив цвет на '#eef', я обломался. Затухания не было. Фон сначала загорался, а потом через время менял свой цвет на изначальный. И только позже, случайно я догадался расписать цвет полностью на '#efefff'.

Следующим моментом стало изменение текстов сохранения. То есть тот текст, который написан на элементе пока идет аякс запрос. Нашел опцию, поставил значение, и... ничего не работает. Оказалось, что некоторые опции (а они задаются ассоциативным массивом) надо задавать особенно. Например опцию 'save_text' надо не просто заключать в кавычки (потому что это строка), а еще и добавлять кавычки внутри самой строки. Иначе это дело парсится без кавычек. Тупизм, неужели создаетли Protoype'а не могли сами ставить кавычки? Приходится теперь писать так:

'savingText' => '\'Сохранение...\''

Кнопочку удаления так же сделал дивом, но это просто. Position: relative, height: 0px, align: right; Надо заметить, что на время редактирования тега, кнопочку надо скрывать, иначе она уезжает вниз и портит вид. А делается это с помощью опции 'onEnterEditMode'. Вот так:

'onEnterEditMode' => 
"function(form, value) { $('delete_".$tag['tag_id']."').hide(); }"

Ну и наконец, сделать надо было системку, которая находит дубликаты тегов. А сделал я так: при сохранении тега, я нахожу ВСЕ теги с таким названием. Если такой тег один (которы мы только что сохранили), то все прекрасно, а если нет, тогда в цикле генерим 2 запроса. Один UPDATE, другой DELETE. UPDATE'ом, все товары, которые были привязаны к дубликату тега перепривязываем к самому первому найденному. Он в итоге остается у нас единственным. А DELETE'ом, удаляем дубликаты. Вот так вот:

$criteria = new Criteria();
$criteria->add(TagsPeer::TITLE, $value);
$duplicates = TagsPeer::doSelect($criteria);
//В качестве итогового тега берем самый первый
if (count($duplicates) > 1) {
  $original = $duplicates[0];
  $query_update = "UPDATE tags_bouquets SET tag_id='{$original->getTagId()}' WHERE tag_id IN(";
  $query_delete = "DELETE FROM tags WHERE tag_id IN (";
  $pass_first = true;
  foreach ($duplicates as $duplicate) {
    if ($pass_first) {
      $pass_first = false;
    } else {
      $query_update .= $duplicate->getTagId().',';
      $query_delete .= $duplicate->getTagId().',';
    }   
  }
  $query_delete = rtrim($query_delete, ',').');';
  $query_update = rtrim($query_update, ',').');';
  $conn = Propel::getConnection();
  $conn->query('BEGIN; '.$query_update.$query_delete.'COMMIT;');
  $this->getUser()->setFlash('notice_duplicated', 'Были найдены и удалены дубликаты тега '.$value);

Результат на картинке. Легкая синева - это как раз затухание фона, я специально мышкой повозил.

По моему плану в поле, обозначающем предка в базе данных у всех должен стоять id родительской категории, а у собственно родительских - 0. Сказано - сделано, создана таблица, заполнена тестовыми данными. Заказчик обрисовал в ТЗ форму редактирования примерно так:

Стрелочки вверх и вниз редактируют порядок категорий. Плюсики - добавление категории или подкатегории.

Обрисовав примерную форму в Admin Generator'e в симфони, я скопировал все сгенерированные файлы в папку модуля, удалил generator.yml, то есть дальше модуль был полностью под моим контролем. Конечно, симфони генерит много необязательного кода, чтобы его убрать требуется время. Например мне сейчас совсем не нужна интернационализация, поэтому я старательно убрал все __() функции и подключения хелперов. Так же сократил количество файлов, мне не нужны были партиаллы header, footer, а некоторые я просто объединил. В итоге у меня оказалось всего 3 партиалла и 2 файла темплейтов.

Тут, собственно, и начинается самое интересное. Чтобы не переписывать шаблоны полностью, я не хотел терять функционала Propel'a и доставал все значения из базы именно им. Но вот тут возник вопрос: "Как вывести массив объектов, возвращенных Пропелом, так, чтобы подкатегории шли сразу за своей категорией?". Решение я придумал довольно быстро - нужно было построить дерево. И вот что я сделал:

$tree = array();
foreach ($array as $element) {
   $parentId = $element->getParentId();
   if ($parentId == 0) {
      $tree['root'][$element->getCatId()] = $element;
   } else {
      $tree['branches'][$parentId][] = $element;
   }
}

Поясню. Если в массиве встречается элемент, у которого $parentId == 0, значит это родительская категория и мы кладем ее среди корневых элементов в $tree['root'][-ид-категории-]. Если же $parentId не 0, значит это подкатегория, и мы кладем ее в одну из веток $tree['branches']['-ид-родителя'][]. Поэтому теперь в темплейте, я могу писать 2 вложенных foreach. Во внешнем я перебираю $tree['root'], а во внутреннем $tree['branches'][-ид-текущего-родителя-]. Код приводить не буду - там много лишних деталей, суть же, надеюсь, я передал достаточно понятно.
Отступ для подкатегорий, кстати, делается так:

#sf_admin_container .sf_admin_subcat_row_0 td:first-child {
  padding-left: 20px;
}
#sf_admin_container .sf_admin_subcat_row_1 td:first-child {
  padding-left: 20px;
}
#sf_admin_container .sf_admin_subcat_row_0 td {
  background-color: #eef;
}

То есть применяем padding-left: 20px только для :first-child.

Следующим трудным моментом стало редактирование/сохранение/создание категорий. Дело все в том, что в данном модуле используется одна форма для редактирования существующих категорий или создания новой и используется функция get..OrCreate (.. - название модели). Так делается в админ генераторе по умолчанию. Идея эта хороша, однако тут мне надо было обрабатывать создание новой категории особенным способом. Если в запросе создания передается cat_id, значит мы создаем подкатегорию, а эта cat_id будет родительской, а если не передаем, значит создается родительская категория. Все было хорошо до тех пор, пока мне не пришлось передавать тот самый параметр cat_id. Проблема была в том, что он терялся среди редиректов и сабмитов. Поэтому при запросе на создание я делал setFlash('force_create', $cat_id). Причем тут 'force_create'? При том, что если я хочу создать категорию и передаю id - симфони ловит его и пытается послать меня не подкатегорию создавать, а родительскую редактировать. Потому что так работает get..OrCreate. Мне пришлось ее редактировать, чтобы при hasFlash('force_create') она создавала новую категорию. Ну и потом при сохранении я достаю этот Flash и вставляю как родительский id. Звучит, наверное, просто, но нервов пришлось потратить много, пока разобрался почему терялся id, как его не терять и как избежать конфликтов. Трудно все-таки, когда одна функция создает категории, подкатегории и редактирует существующие.

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

$query = "UPDATE categories SET order_num = CASE
       WHEN cat_id = '".$cat_id."' THEN '".$demoting_num."'
       WHEN parent_id='{$promoting_parent}'
          AND order_num='{$demoting_num}' THEN '".$promoting_num."'
       END
       WHERE cat_id IN (".$cat_id.")
          OR (parent_id={$promoting_parent} AND order_num={$demoting_num})";

Вот так весело прошел день моей работы. В результате я получил вот такую симпатичную формочку

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

Собственно для тех, кто не хочет ждать, а хочет кода - кладем это дело в frontendConfiguration.php:

class frontendConfiguration extends sfApplicationConfiguration {
  public function configure()  {
  $this->dispatcher->connect('routing.load_configuration', array('registerRoutes', 'listenToRoutingLoadConfigurationEvent'));
  }
}
 
 
class registerRoutes {
  static public function listenToRoutingLoadConfigurationEvent(sfEvent $event) {
  $routing = $event->getSubject();
 
  $criteria = new Criteria();
  $criteria->clearSelectColumns();
  $criteria->addSelectColumn(StaticPagesPeer::LINK_NAME);
  $pages = StaticPagesPeer::doSelectStmt($criteria);
 
  foreach ($pages->fetch() as $link) {
    $routing->prependRoute(
      'static_'.$link,
      new sfRoute(
       '/'.$link,
      array(
          'module' => 'main', 
          'action' => 'static', 
          'page' => $link)
    ));
    //with slash
     $routing->prependRoute(
        'static_'.$link.'_with_slash',
        new sfRoute(
        '/'.$link.'/',
          array('module' => 'main', 
          'action' => 'static', 
          'page' => $link)
     ));
}
}
}

Тут я из базы выбираю поля link_name, и создаю правила на их основе. Каким образом это дело крепится к инициализации роутов - я не знаю. На остальные вопросы отвечу в комментариях.

Тем, кто изучает симфони известно, что админку часто делают через "generate:app backend". То есть мы создаем приложение внутри нашего проекта. Это прекрасно, но есть одно НО. Чтобы нам зайти в админку требуется писать http://project/backend.php/some-admin-pages. Можно конечно обьяснять заказчикам, что мол понимаете, это другое приложение внутри проекта, другой фронт-контроллер, так надо. Но лучше сделать иначе. Скажу сразу, этот метод взят с официального форума симфони. Но найти его проблематично.

Метод таков:

1. Создаем папку "admin" внутри папки "web". Копируем туда .htaccess из той же "web", и заменяем
   RewriteRule ^(.*)$ index.php [QSA,L]
   на
   RewriteRule ^(.*)$ ../backend.php [QSA,L]
2. Идем в настройки роутинга для backend (app/backend/config/routing.yml) и добавляем папку /admin/ ко всем роутам. Например:

   # default rules
   homepage:
   url: /admin/
   param: { module: default, action: index }

3. Меняем no_script_name на "on" в настройках backend (app/backend/config/settings.yml):
   prod:
   .settings:
   no_script_name: on
4. Чистим кеш и заходим в папку: http://project/admin/ без проблем.
]]> http://www.charnad.com/blog/symfony-chelovecheskoe-raspolojenie-adminki/feed/ 2 http://www.charnad.com/blog/documentacia-symfony/ http://www.charnad.com/blog/documentacia-symfony/#comments Wed, 18 Feb 2009 09:35:44 +0000 CharnaD http://www.charnad.com/?p=367

Сейчас по долгу службы я работаю над движком для одного сайта. И сделать я его решил с использованием фреймворка, о котором слышал много хорошего. Я говорю о Symfony. Заниматься копипастом хвалебных речей с других сайтов я не буду, сам писать подобное так же не буду. Скажу только, что поначалу мне было трудно разобраться. Я даже хотел все бросить и писать на своей простой MVC системке, но в итоге не бросил. Упорно читал мануалы, стал понимать принципы построения приложения с использованием симфони. Собственно тут я хочу лишь выложить ссылки, которые могут помочь тем, кто будет изучать symfony.

Конечно, ссылка номер 1 это ссылка на главный сайт: http://www.symfony-project.org/
Там большое количество документации, которые стоит осилить. Я пожалел времени, начал рубить сплеча, однако сейчас все равно пришел к тому, что надо читать мануалы и я их читаю. И всем придется, кто хочет понять всю мощь этого фреймворка.

Ссылка номер 2 - это ссылка на главный гайд "симфонистов" The Book (PDF). Книга на английском. Методично рассказывается о всех сторонах фреймворка.

Ссылка номер 3 - это практическое руководство, так называемые Askeet (PDF) и Jobeet (PDF). Они обе используют Propel в качестве ORM вендора (на есть вариант и для Doctrine). Имейте ввиду, что Askeet был написан для Symfony 1.0, а Jobeet для 1.2. В сети есть переводы некоторых глав на русский.

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

]]> http://www.charnad.com/blog/documentacia-symfony/feed/ 2