Но стоит отметить интересный доклад по Propel 1.5, который просто поражает своим ростом функциональности и удобства за столь короткий срок после выхода версии 1.4 и по новому form framework, который обещает построение форм любой сложности без бубна.

Propel 1.5 позволяет использовать Namespaces в файлах описывающих вашу модель если вы используете в работе php версии 5.3

Добавить использование моделей очень просто:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<database name="bookstore" namespace="Bookstore" defaultIdMethod="native">
<table name="book">
<!-- -->
</table>
<table name="author">
<!-- -->
</table>
</database>
А в классе модели:
<?php
// use fully qualified name
$book = new \Bookstore\Book();
// or use an alias
use Bookstore\Book;
$book = new Book();
// remember to use the \ namespace for core Propel classes in this case
$con = \Propel::getConnection();
$book->save($con);
Более подробнее можно прочесть в блоге Francois Zaninotto

так же набирается help team для конференции – это те люди, которые будут помогать в закулисных делах конференции, если у вас есть желание помочь при регистрации в поле дополнительная информация укажите “хочу в help team”

• 50 web серверов, обрабатывают по 5000 запросов в секунду
• 17 серверов баз данных
• 30 memchache серверов, общий объем памяти 210 Гб
• 1.2 petabytes на хранение данных

Этот список не влючает сервера по кодированию видео и обработке поисковых запросов.

В общей сложности сайт обслуживают 450 шт. серверов.

Изначально мы планировали до 50 человек, но приехало больше 80, это нас очень порадовало.  Обрадовали нас и орендадатели зала выделили в честь такого большого количества людей и зал побольше, за что им отдельное спасибо!

Мои доклады на конференции:

Все доклады можно посмотреть на сайте нашего комъюнити symfony.org.ua, а так же на http://www.slideshare.net/tag/uasymfonycamp

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

Мероприятие будет проходить по адресу: Киев, ул. Предславинская, 12 (http://predslavinskaya.com.ua/). Партнер и соорганизатор SymfonyCamp - WorldWebStudio

Программа конференции еще составляется.

Желающие посетить мероприятие – пишите на  movchan@gmail.com.

Если же не против выступить с докладом – в письме указывайте название доклада.

Начиная с версии 1.2.x, больше мы как прежде сделать не можем, так как всем правят формы.

Соответственно вместо внесений в generator.yml, нужно сделать изменения в классе форм.

В моем примере у меня есть класс  Album в котором есть поле Album Cover (обложка альбома), для того чтоб облажка была файловым полем, обвновляем класс формы AlbumForm.class.php (который создается автоматически) и вставляем в него следущее:

class AlbumForm extends BaseAlbumForm
{
  public function configure()
  {
    $this->setWidget('album_cover', new sfWidgetFormInputFile());
    $this->setValidator('album_cover', new sfValidatorFile(array('path' => 'uploads/', 'required' => false)));

  }
}

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

Оригинал blog.rajatpandit.com

На сегодняшний момент нельзя посмотреть live версию проекта в интернете и я решил исправить эту ситуацию.

Рад представить все интресующимся и использующих в работе symfony, доработаную версию проекта jobeet до презентабельной версии, которую вы можете поклацать на сайте jobeet.com.ua

В ближайшее время для всех желающих svn проекта http://subversion.assembla.com/svn/ijobeet.

Чего коснулись доработки:

• Основная проблема – это non-latin кодировки, для которых нет коректной ASCII версии символов. Говоря простым языком, jobeet использует библиотеку iconv для транслитерации всех не латинских символов в ASCII и тут же наступает на габли, связаные с таким перекодированием.  Функция iconv возвращает на славянские символы – пустой результат, по-этому от транслитерации временно пришлось отказаться
• Из первой проблемы вышла вторая – это поиск, который использует движок Lucene, через прокси фреймворка Zend. И тут ситуация повторяется, так как Lucene использует для создания индекса ASCII снова возникает проблема с non-latin кодировками и корректным из индексированием.
  Благо тут на помощь приходит то, что Zend позволяет использовать для индексирования кодировку UTF-8 (с определенныим ограничениями, о них можно прочесть в офф. документации Zend Framework). Вот собственно переход на utf-8 и был осуществленн для корректной индексации и поиска.
• Добавлен русский перевод
• Небольшой ряд мелких исправлений, я не буду на всех останавливаться, практически все исправления описаны в коментариях к коммитам в svn

Все желающие разместить у себя на сайте список ИТ вакансий, в ближайшее время будет доступен API и примеры информеров.

Роутинги как объекты класса

До symfony 1.2, система роутинга (через класс sfPatternRouting ) хранила роуты в ассоциативном массиве. Старая система отлично работает, но при этом трудно настраиваемая под свои нужды. Для того чтоб дать разработчикам свободу в модификации и улучшении процесса роутинга, в новой версии все роуты хранятся как массив объекта sfRoute.

Роутинг 1.2 совместим с 1.1 и не требует никаких дополнительных изменений в routing.yml файле.

Если вы хотите прописать роуты напрямую в PHP, теперь нужно указывать объект sfRoute вторым аргументов для методов connect(), preprendRoute(), appendRoute(), и insertRouteBefore() :

$routing->connect('foo_bar', new sfRoute('/foo/:bar', array('module' => 'foo', 'action' => 'bar')));

Настройка роута

Конструктор класса sfRoute принимает последним аргументом массив опций, который позволяет легко настраивать роуты. В конфигурационном файле routing.yml , ключ options применяется для замены настроек по умолчанию:

article:
  url:     /article/:id-:slug
  options: { segment_separators: [/, ., -] }  

В опции segment_separators  указываются символы разделители для роута. В предыдущем примере как разделитель  испольются - (дефис), которые в нашем случае так же валиден как и два разделителя встроенных по умолчанию (/ и .). Таких образом допускаются ссылки вида /article/1-my_article_title с переменной id равной 1 и slug равной my_article_title.

Эта опция уже доступна в symfony 1.1, но только глобально для всех роутов. Таким образов добавив глобальный разделитель, вы можете нарушить работу роутингов определенных в сторонних плагинах.

Кроме этого доступно еще две новых опции:

• generate_shortest_url: генерация коротких URL, насколько это возможно 
• extra_parameters_as_query_string: генерация дополнительных параметров в виде запроса

Эти опции могут быть заданы глобально либо отдельно для каждого роута. По умолчанию обе опции равны false в factories.yml для того чтоб сохранить совместимость с предыдущими версиями symfony.

Пример того как использовать эти опции для настроки роутов:

articles:
  url:     /articles/:page
  param:   { module: article, action: list, page: 1 }
  options: { generate_shortest_url: true }  

Этот роут генерит максимально короткий URL. Т.е. если запросить page равное 1, что является значением по умолчанию для переменной page, на выходе получим URL вида /articles:

echo url_for('@articles?page=1'); // generates /articles
// would have been /articles/1 in symfony 1.1   

echo url_for('@articles?page=2'); // generates /articles/2  

Другой пример, как работает опция extra_parameters_as_query_string:

articles:
  url:     /articles
  options: { extra_parameters_as_query_string: true }  

Такой роут принимает дополнительные параметры, которые не валидны для переменных заданных в патерне роута (в самом примере таких переменных как мы видим вообще нет):

echo url_for('@articles?page=1'); // generates /articles?page=1
// would not have matched the route in symfony 1.1

echo url_for('@articles?page=2'); // generates /articles?page=2  

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

Настройка роутингов

Вся логика из класса sfPatternRouting была перемещенна в объект sfRoute:

• Когда пришел HTTP запрос, объект роутинга опрашивает каждый роут не совпадает ли он с зпрошеным URL.
• И в момент когда вы хотети сгенерировать URL, объект роутинга опрашивает каждый роут на возможность сгенерировать URL по предоставленным параметрам.

Добавление всей логики в класс роутига, в этом случае не важно либо это создание нового класса роутинга для иземения направления парсинга роутов либо генерация всего процесса роутов.

Если вы хотите изменить класс обработки роутов используемый по умолчанию на свой, добавьте ключ class в файл конфигурации роутов:

article:
  url:   /article/:id
  param: { module: article, action: index }
  class: myRoute  

С такой конифгурацией ротинга, для обработки роута article symfony будет использовать класс myRoute, вместо стандартного класса sfRoute. И теперь роуты будут зависить от поведенния заданного в вашем классе.

Новый класс sfRoute намного модульнее чем старый sfPatternRouting, что позволяет легко настраивать стандартное поведение класса.

Стандартный sfRequestRoute

В Symfony есть стандартный класс роутинга, sfRequestRoute, который можно применять в ходе процесса сопостовления HTTP метода:

article:
  url:          /article/:id
  requirements: { sf_method: get }
  class:        sfRequestRoute  

В представленной конфигурации роутинга, роут article будет совпадать только запросу с HTTP методом GET.

Если вы хотите задать несколько роутов с одинаковым url, но с разными методами, вы можете добавить параметер  sf_method во время генерации роута:

<?php echo link_to('Great article', '@article?id=1&sf_method=get')) ?>  

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

• method: HTTP метод
• format: формат запроса 
• host: имя хоста 
• is_secure: был ли запрос вызван через HTTPS или нет 
• request_uri: полный запрошеный URI  
• prefix: префикс добавляемый к каждому сгенерированному запросу

В общем sfRequestRoute – это первый шаг на пути к простой архитектруре.

Что дальше?

В следующей части, мы познакомимся с тем как symfony управляет рессурсами при автоматической генерации роутов основанных на простой конфигурации файла routing.yml.

О новой системе роутинга будет доклад на symfonyCamp с большим количеством примеров и живим демо, так что все желающие пока еще не поздно регистрируйтесь.

Если вы хотите следить за процессом внедрения изменений в symfony 1.2 проверяйте переодически страницу upgrade to symfony 1.2 все новинки будут появлятся на ней в по ходу появляния.

Но существующаю система работы с плагинами не может ответить на вопросы:

• А есть ли плагин который добавляет “вот такую штуку” ?
• А поддерживает ли мой любимый плагин новую версию symfony 1.1?
• А совместим ли плагин с Doctrine?
• А какие самые популярные плагины?
• Как я могу помочь доработать плагин?

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

Ну и вот теперь у нас есть совершенно новый раздел “Plugins” (в верхнем меню), который и дополнил старый добрый Trac.

Что умеет

Ниже список фич новой системы плагинов:

• Страница плагинов отображает все существующие на данный момент плагины, их можно отсортировать по версии symfony, по используемой ORM модели, по автору либо по имени плагина
• У каждого плагина, как и раньше, есть отдельная страница, с информацией о плагине, с текстом лицензии, с процессом установки, readme, зависимостями, списком релизов отсортированным по версиям symfony и админ панелью для разработчика плагина. Эту страницу так же можно настроить под каждую версию отдельно.
  
• Вся информация залинкована между собой, это означает что вы легко можете найти всех разработчиков плагина, либо все плагины выбранного разработчика
  
• Владелец плагина (его главный разработчик) получает доступ к админ панели управления плагином (редактирование описание, категорий, …), загрузке новых релизов и управлнию командой разработчиков плагина.
  
• Над каждым плагином могут работать несколько разработчиков с разными правами (ролями):
  - девелопер: имеет доступ к репозиторию плагина (если он расположен в  репозитории symfony)
  - сборщик: может загружать новые релизы и удалять старые
  - владелец (лидер): что хочет то и делает с плагином
• Теперь если вы хотите помогать в разработке существующего плагина, достаточно попросить доступ у Владельца плагина. Этот процесс очень прост, так как сейчас все автоматизировано, от создания акканута до авторизации в SVN
  
• Категории к которым относятся плагины, может выбирать владелец (главный разработчик) админ панели управления плагином. И когда большую часть плагинов растусуют по категориям, появится возможность на главной странице плагинов отсортировать их еще и по категориям.
• Все trac аккаунты были перенесены в новую систему, и сейчас вы можете залогинится с вашим существующим trac аккаунтом. Т.е. одинаковые аккануты сейчас используются для Trac, Плагинов, и Subversion.

Для разработчиков плагинов

Во время переноса в новую систему, произошли некоторые изменения. Ниже спискок главных моментов, которые нужно учитывать при разработке плагинов:

• Информация о плагине, отображаемая на странице плагинов, берется из файла package.xml. Поэтому все владельцы плагинов, должны проверить и исправить свои package файлы.
  
• Раздел “Лицензий” в админ панеле плагина, покажет файл ЛИЦЕНЗИИ PEAR пакета, если он есть. Если его нет, то пожалуйста добавьте его в корень вашего PEAR пакета с текстом самой лицензии.
  
• Раздел “readme” покажет файл README. Формат этого файла сменился с Trac wiki markup на Markdown, так как этот формат используется во всей документации symfony. Конвертация в Markdown из Trac wiki markup, происходит автоматически, но так как она оставляет желать лучшего, нужно сомстоятельно проверить файл README на соответствие Markdown синтаксису
  
• Скрипт импорта автоматически связал владельца плагина с его плагином, но это сработало если email в вашем trac аккаунте совпадал с email’ом, который вы указали с файле package.xml. На данный момент порядка 85 плагинов не имеют хозяев (налетаем и разбираем, кому плагинчик!). Если вы владелец плагина и вы не можете получить к нему доступ, отправьте письмо с именем вашего плагина и логином Фабьену (fabien.potencier[at]symfony-prokect.com)
  
• Некоторые плагины не были перенесены так как были с ошибками.
  Если вы не нашли своего плагина в новой системе, тогда посмотрите на странице плагинов с ошибками для того чтоб узнать причину. Если не знаете как побороть возникшую проблему, пишите Фабьену должен помочь
  
• Страница с плагинами в Trac перенаплавляется на новую страницу плагинов, так что пользователи попадут туда куда хотели.

В завершение

Новая система плагинов не заменяет текущую Trac систему, и так же не предлагает SVN репозитории для плагинов. Это потому что новая система не заменяет систему формирования проекта symfony. Разработчики все еще трудятся над такой системой, которая предоставит для наших плагинов выделеный SVN репозиторий, систему трекинга, wiki, и еще кучу всего разного… Так что оставайтесь на связи!