Последним можно облегчить жизнь потому что есть такая штука как Propel Criteria Builder.

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

Стало намного красивее и удобнее.

Тема для обсуждения

• Cherkassy
• Kyiv (Ukrainian capital)
• Kharkov (Ukrainian East Economic and Cultural Center)
• Lvov (Ukrainian West Economic and Cultural Center)

Two speakers couldn’t attend the conference because of reasons beyond the control. But this didn’t prevent us to make this event at good level (we keep it from common beer-bidge ?)

First, we were looking for more Symfony specialists, who are using the framework in everyday work as main tool. More conference participants were beginners in Symfony, or were only looking for best and powerful solution for web-development.

During the conference we’ve acquainted beginner “symfonians” with power of Symfony framework, have developed simple web-application at real time, have talked about Symfony 1.1 Forms with practice examples. Also we had possibility to discuss weak points of the framework and typical problems, which meet developers during web-application building process.

The meeting was finish with collective beer-drinking.

Photos:

Alex Vasilenko (Glad) - Jelv

Roman Movchan (Roman) - Bеб-цех

Vladimir Dybenko - Jelv

Roma Shalabanow (Dreammaker)

И хотя, обстоятельства помешали приезду двоим докладчикам из Киева и Харькова, в целом можно констатировать, что мероприятие прошло хорошо и на должном уровне (мы не позволили сделать из конференции обычную пьянку :)).

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

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

Встреча была завершена коллективным распиванием алькогольных напитков…

Код который писался на конференции я выложил на сайте.

Фотки:

Александр Василенко (Glad) - Jelv

Роман Mовчан (Roman) - Bеб-цех

Владимир Дыбенко - Jelv

Рома Шалабанов (Dreammaker)

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

Мероприятие будет проходить по адресу г. Черкассы, ул. Университетская, 33, офис 53 (здание БТИ).

Для связи с организаторами и для подтверждения участия, можно звонить по телефонам:

8 (0472) 56-15-88 - Роман
80938454404 - Владимир

Программа на сегодняшний день выглядит так:

• 10:00 – 10:30. Вступительное слово от организаторов.
• 10:30 – 11:30. Демченко Александр: «Роутинг в Symfony 1.1 и выше»
• 11:30 – 12:30. Игорь Бровченко «Интернационализация в Symfony»
• 12:30 – 13:30. Демченко Александр: «Новые возможности Symfony 1.2»
• 13:30 – 14:30. Кофе-брейк
• 14:30 – 16.00. Дискуссии

Программа очень примерная, мы будем стараться увеличить количество докладов и сократить время выступления до 20 минут.

Стоимость участия в конференции - 0 грн 00 коп.

Для участников из г. Києва: маршрутки отправляются каждые полчаса со станции Черниговская и Вокзальная.

<IfModule mod_rewrite.c>
# This is an Apache configuration directive that designates this section
# is processed conditional on the presence of the mod_rewrite module
# being loaded.
# Simply, if mod_rewrite hasn't been installed and loaded, everything
# is skipped until the </IfModule>.
# Note, that just because this *section* is processed does not necessarily
# mean the *rewrites* will be processed. For that, we need to turn the...
RewriteEngine On
# . Now the rewrites will be processed.
# uncomment the following line, if you are having trouble
# getting no_script_name to work
RewriteBase /
# This directive explicitly sets the base URL for rewrites by stripping the
# local directory prefix before processing, and applying rules only to the
# remainder. Then, when processing is complete, the prefix is added back to
# the path. Here, all it does is strip the leading root slash, so a call to
# http://example.com/module/action/var/value
# will be processed by rewrites as
# module/action/var/value
# we skip all files with .something
# RewriteCond directives add a condition to which the next RewriteRule
# directive is subject. So, if and only if the following two RewriteCond
# directives match will the ".* - [L]" rule below them be used. Otherwise,
# if either RewriteCond directive does not match, the ".* - [L]" rule is
# skipped, and processing continues.
RewriteCond %{REQUEST_URI} \..+$
# This RewriteCond matches if there is one or more characters between a
# dot and the end of the request URI.
# Simply, this condition can be read as "match if the URI ends with a
# file name and extention."
# http://example.com/module/action/var/value would NOT match
# http://example.com/css/ would NOT match
# http://example.com/css/main.css WOULD match
# http://example.com/someSingleFile.html WOULD match, but then…
RewriteCond %{REQUEST_URI} !\.html$
# This RewriteCond matches if the request URI does not end with ".html".
# Simply, this condition can be read as "match if the URI does not end
# with 'a dot followed by the four characters h, t, m, and l'."
# http://example.com/module/action/var/value WOULD match
# http://example.com/css/main.css WOULD match
# http://example.com/someSingleFile.html would NOT match
# Plain HTML files are dealt with differently, so the combined effect of
# these two conditions is that they are skipped here and matched later
# to be processed by a different rule.
RewriteRule .* - [L]
# Combining the two conditions above, one could say this rule will only
# be used if the URI ends with a file name and extension, unless that
# extention is 'html'. This is why JavaScript and CSS files are accessible
# while the directory containing them is not:
# Because http://example.com/css/main.css statisfies both rules in that it
# - has a file name and extention, and
# - that extension is not 'html'
# However, http://example.com/css/ or http://example.com/css would not
# use this rule, because neither includes a file extension. This rule would
# be skipped, and processing of further rules would continue.
# In other news, this rule has the [L] flag set, which means that if this
# rule is used, the processing of rules stops, and Apache is directed to
# service the request with the URI as rewritten by the rule. In this case,
# that rule is to match everything (the pattern .* means "zero or more
# characters of any kind" which will match the entire URI) and pass it
# along unchanged (which is what the dash is for; it does nothing).
# we check if the .html version is here (caching)
# Remember how the last rule had an exception for files ending in ".html"?
# This is where those files are dealt with.
# Something of note here is that there are multiple RewriteRule directives
# followed by a single RewriteCond directive. In the group above, it was
# the other way around: one rule subject to several conditions. As long as
# the [L] flag isn't set, each rule does it's rewriting and just passes
# processing along. This way, the original URI can be massaged and prepared
# for any conditions or rules that might follow. This will make more sense
# in a bit.
RewriteRule ^$ index.html [QSA]
# This rule matches on an empty string, and then adds "index.html"
# Simply, this rule can be read as "if the URI is requesting the root
# directory, rewrite it so it is requesting the file 'index.html' in
# the root directory."
# This rule would turn
# http://example.com/
# into
# http://example.com/index.html
# Either way (whether this rule is used or not) processing continues to…
RewriteRule ^([^.]+)$ $1.html [QSA]
# which adds '.html' to the URI if it has no extention. Obviously, this
# means that this rule and the previous rule are mutually exclusive, since
# using the last rule rewrites the URI such that this rule will fail.
# (In fact, that rule does exactly what this rule does plus a little. That
# rule could be simplified to just "^$ index [QSA]", and then both rules
# would be used, and everything would function exactly the same, but that's
# not really here nor there. I'm just sayin'.) So, anyway….
# This rule turns
# http://example.com/foo
# into
# http://example.com/foo.html
# Literally, this rule could be read as "if there are one or more characters
# from the begining of the request to the end of the request that are not
# a dot, add a dot followed by the four characters h, t, m, and l" or
# more simply as "if there isn't a dot anywhere in the request, add '.html'
# to the end of it."
# At this point, the URI will be of one of three possible forms:
# http://example.com/index.html if the first rule matched,
# http://example.com/foo.html if the second rule matched, or
# http://example.com/foo.bar if neither rule matched.
RewriteCond %{REQUEST_FILENAME} !-f
# This takes the result after using the previous rules, and
# uses it to apply a condition on the following rule.
# "%{REQUEST_FILENAME}" tries to resolve the resulting URI to a location
# in the filesystem. The "-f" takes that location, and tests whether or not
# it exists, and if so, is a regular file. Recall that an exclamation point
# negates the test it precedes.
# So this can be read as "match if the processed URI does not correspond
# to a file on disk."
# no, so we redirect to our front web controller
# Hence, this rule will only be used if the rewritten URI does not
# resolve to a regular file on the file system.
RewriteRule ^(.*)$ index.php [QSA,L]
# This rule matches any non-empty URI (which by this point is a "can't happen"
# state, since the "^$ index.html [QSA]" rule made that impossible). So…
# This rule matches any URI that made it this far, and completely rewrites
# it to "index.php" alone, appends the query string ([QSA] flag), and stops
# processing any further rules ([L] flag).
# According to the previous RewriteCondition directives, the only way this
# rule would not be used is if the URI corresponds to a file on disk, in
# which case (since rewrite processing is stopped at this point) that file
# would be directly served up by Apache. Either way, service of this
# request is complete…
</IfModule>
# big crash from our front web controller
# …unless it isn't.
# If none of the above rules caused Apache to kick in and start serving the
# request by either fetching the file from disk or sending the request to
$ Symfony's front controller (including the case where the rules weren't
# processed because mod_rewrite.c wasn't loaded), then something is
# clearly very wrong, and the whole thing dies.
ErrorDocument 500 "<h2>Application error</h2>symfony application failed to start properly"

место проведения - ул. Университетская, 33, офис 53
начало в 10.00

темы докладов будут позже в этом топике

примерные тезисы для обсуждения

- unit тестирование для симфони 1.1
- методы рефакторинга
- ajax
- накат новой версии без потери данных на пром сервере

связь с организаторами по телефону:
8 (0472) 56-15-88 - Роман
80938454404 - Владимир

Если вам наравится фреймворк symfony, пожалуйста уделите пару минут и проголусуйте “ЗА” (vote for) symfony:

1. Зарегистрируйтесь как пользователь по следуйщей сылке: http://www.netbeans.org/servlets/Join (вам нужно указать желаемый логин и email)
2. Проверить почту и  пройти по ссылке для создания пароля на ваш новый аккаунт.
3. Дальше заходим на стараницу: http://www.netbeans.org/issues/show_bug.cgi?id=145913
4. Находим ссылку “Vote for this issue” (находится внизу формы, в форме ничего не трогаем)
5. Откроется страница с таблицей, листаем вниз пока не увидим строку с записью “145913 Support for symfony”.  Теперь ручками вбиваем “1″ в текстовое поле, что означает что вы голосуете “ЗА” symfony.
6. Нажимаете на кнопку“Submit” в самом низу страницы, это и будет означаться что вы проголосовали.

Это уникальная возможность поддержать symfony, потому что NetBeans один из широко распространненых сред разработки и поддержка им symfony позволит привлечь больше новичков к изучению и использованию symfony, ну и конечно будет отличной новостью для профессионалов.

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

До 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 все новинки будут появлятся на ней в по ходу появляния.

Оригинал статьи на русском 451f.com.ua

my_product_i18n:
_attributes: { phpName: ProductI18n }
id:          { type: integer, required: true, primaryKey: true, foreignTable: my_product, foreignReference: id }
culture:     { isCulture: true, type: varchar, size: 7, required: true, primaryKey: true }
name:        { type: varchar, size: 50 }
created_at:  { type: datetime }

Рабочий пример для enum, datetime, tinytext, date:

my_product_i18n:
_attributes: { phpName: ProductI18n }
id:          { type: integer, required: true, primaryKey: true, foreignTable: my_product, foreignReference: id }
culture:     { isCulture: true, type: varchar, sqltype:enum, size: "'ru_RU','uk_UA','en_EN'", default: ru_RU, required: true, primaryKey: true }
name:        { type: varchar, size: 50 }
description: { type: longvarchar, sqltype:tinytext }
year:        { type: date, sqltype:year }
year2:       { type: varchar, sqltype:year }
created_at:  { type: timestamp, sqltype:datetime }

Зачем столбец culture переделали в тип enum? С точки зрения оптимизации базы данных. Минусы такого решения:
• языки указываются жестко
• админка ещё не проверялась

Единственное, что не удалось так это задействовать тип столбца set.

Ссылки по теме:
• Propel user guide: Column Types
• Propel ticket #462: more datatypes for mysql
• Propel ticket #77: Add ENUM support for MySQL

Источник: Журнал веб разработчика: Объявление типов столбцов (enum, datetime, tinytext, year) для MySQL, которые явно не поддерживаются в Propel 1.3