О том как установить Kohana легко найти в интернете. Вкратце: скачать, распаковать, запустить install, удалить install. Про то, как убрать index.php из адреса тоже пару слов всего: переименовать example.htaccess в .htaccess и убрать index.php из $config['index_page'] в конфиге.

Собственно постороение приложения на Кохане я начал с того, что захотел переписать на этом фреймворке скриптик по удаленному управлению сайтами. И первая задача - формочка добавления сайта в БД. И тут возникли первые проблемы. Компоненты для построения форм, которые описаны в туториалах: Forge и Formation. Я выбрал Formation, скачал, установил. Не работает, выдает ошибки. Гуглил, читал форумы, боролся. От безысходности постучался в аську к одному парню, который имел дело с Коханой и получил ответ, что Forge и Formation блин уже deprecated. Как вам такое? На сайте я не видел об этом ни слова. Может не там искал?

Ладно, пошел я дальше искать модуль для создания формочек. Посоветовали мне Morf. Зашел на страничку проекта. А там такой тухляк.. полгода код не обновляется, висит один тикет и еще два закрыто. Понятно все, не надо нам добра такого. В общем остался последний модуль на который были все надежды - Formo.

Formo завелся сразу, подключился без особых хлопот.  Только вот одна проблема, форму мне выводит с помощью P и DIV, а мне проще в TABLE запихать. Стал искать способы заставить генерить форму по-другому. Модифицировал объект, менял настройки - фиг. Нашел в мануале статью по темплейтам, переделал под темплейт. Не работает. Оказалось пример приведен с использованием шаблонизаторов, коими я не пользуюсь. В итоге кое-как заставил генериться форму как надо.

С валидацеий тоже номер. Искал как в валидацию передать $_POST, чтобы сверить с установками. Оказалось, что Formo сама жрет POST. Так же сама делает repopulation, основываясь на имени таблицы и hidden инпуте. Пока этого не знаешь - пугаешься и мучаешься, когда узнаешь - становится просто и легко. После чего за два дня доделал простейший CRUD.

Общие впечатления о фреймворке на этот момент:
1. Наименования классов xxx_Core, когда вызываются они new xxx(); ломает автокомплит из-за чего надо совать IDE отдельный файлик, где прописаны "class xxx extends xxx_Core {}".
2. Документация местами ужасна. Референс мануал нормальный, референс есть референс. Но вот тьюториалов мало, документация модулей слабая, коммьюнити маленькое. В общем въезжать тяжело.
3. Местами все все-таки достаточно просто. За 10 минут добавил себе пару нужных хелперов, за полчаса написал плагин к Formo. И то, и другое я выложу чуть попозже.
4. Дурацкие сообщения об ошибках. Если я ошибся и сунул не тот параметр, который ожидается - вылезает Fatal error где-то в глубине ядра. О том, что это я ошибся в параметре, а не Кохана концы отбрасывает можно только догадываться.
5. ORM успел посмотреть на уровне CRUD одной таблицы. Удобно.

У меня в базе данных введен в таблице специальный столбик, называемый 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);

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

Собственно для тех, кто не хочет ждать, а хочет кода - кладем это дело в 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