Блог FX’а

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

Тем временем Fabien (главный разработчик Symfony) разродился кучкой постов:

• Изменение структуры директорий в проектах на Symfony 1.1.
• Отсылка писем в Symfony 1.1 с помощью Swift Mailer. В версии 1.0 для этого использовался PHP Mailer, обернутый в симфониевский декоратор.
• Как создать оптимизированную под iPhone версию вашего сайта с помощью Symfony. За неприглядным (как по мне) названием лежит интересный рассказ о форматах представления и mime-type’ах. Советую почитать, очень интересно. Ах да, про iPhone всё-таки не забыли. :)

written by FX Poster \\ tags: PHP, Symfony

Что бы вы предпочли - datepicker или 3 select’а для дня, месяца и года?

У нас на проекте мнения разделились, потому решил устроить опрос…

written by FX Poster

Собственно, продолжим начатое…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$ pear install symfony/symfony

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

$ pear install symfony/symfony-beta

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

$ pear upgrade symfony/symfony

или

$ pear upgrade symfony/symfony-beta

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

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

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

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

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

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

Ссылки:

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

written by FX Poster \\ tags: PHP, Symfony

Ну что ж, начнем повествование…

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

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

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

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

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

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

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

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

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

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

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

</form>

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

written by FX Poster \\ tags: PHP, Symfony

Засел я сейчас за написание давно обещанной статьи про новый Form Framework, который будет включен в состав Symfony 1.1. Пока разобрался, что и как подключать - Symfony 1.1 Sandbox упорно не хотел работать с базой данных так, как нужно было бы, пока поглядел в кодах - что и как нужно делать (а то порядком уже подзабыл всё, что я смотрел при прошлом просмотре Symfony 1.1). В общем, решил я, что одной статьей дело не обойдется - слишком уж много всего рассказывать нужно, так что с завтрашнего дня я буду выкладывать одну статью в день, которые будут касаться форм в Symfony 1.1. Эти статьи можно будет считать “русским аналогом” вот этого цикла статей - это не будет перевод статей, скорее я буду руководствоваться тем, что написано там, чтобы знать, куда дальше двигаться в своем повествовании, при этом, возможно, останавливаясь на некоторых моментах, которые, на мой взгляд, достаточно важны для новичков в Symfony.

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

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

written by FX Poster \\ tags: PHP, Symfony

Собственно, возникла проблема - заказчик хочет на сайте URL’ы определенного вида. Всё бы ничего - но то, что он хочет очень сильно расходится с тем, как работает сам сайт. Так вот, задание таково - нужно написать регулярку, которая бы выдавала true на всё, не включая (account|comment|user). В принципе регулярку такую я составил: /(?!(account|comment|user))/. Проблема в том, что рутинговая система накладывает свои ограничения на регулярки, а точнее приписывает к ним слева и справа свою фигню: '#^(?:\\/(<вот сюда можно вставлять всё, что угодно>))?$#'. Вопрос таков - можно ли что-то вставить в средину последней регулярки так, чтобы она вела себя как и моя, описанная выше. Если да - подскажите, что вставлять, а нет - так нет, буду через mod_rewrite решать проблему.

written by FX Poster

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

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

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

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

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

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

written by FX Poster \\ tags: PHP, Symfony

Чем больше я работаю над своим первым проектом на работе, тем больше мне хочется в нем поменять и тем больше я жалею о том, что перед началом работы я не прочитал до конца «The Definitive Guide to Symfony» и не изучил плагины для Symfony. Многие из них мне бы помогли намного сократить время разработки и, что самое главное, не думать о том, как красиво реализовать те или иные вещи… И еще одно — если у вас уже есть кусок системы (как это было у меня), который вы собираетесь переписывать с использованием вашего фреймворка (или просто переписывать, потому что код вам не нравиться) — то мой вам совет — потратьте время на то, чтобы спроектировать этот кусок на план вашей новой системы, не бросайтесь сразу всё переписывать (каюсь, я поступил именно так), так как после анализа (который, возможно, займет у вас не один день, и даже не одну неделю), возможно, от предыдущей архитектуры системы не останется и следа.

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

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

Continue reading »

written by FX Poster \\ tags: Django, MVC, ORM, PHP, Symfony

В процессе написания сайта с использованием Symfony начали проявляться недостатки этой замечательной, на мой взгляд, библиотеки…

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

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

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

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

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

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

written by FX Poster \\ tags: PHP, Propel, Symfony

Эх, млин. Список вопросов на выдали, но, судя по тому, что было на консультации (я не был, работал), вопросы будут не эти…  Ладно, посмотрим.

PS. А потом верстать, верстать, верстать, верстать…

PPS. Обьясните мне, бедному и непонимающему студенту, нахрена было делать это! Кто скажет “ну, типа чтобы генерить JS на серверной части” очень советую глянуть в сторону Symfony, а точнее - её JS-helper’ов. Вот в таком есть смысл, а в JQuery-PHP я его не вижу пока что…

written by FX Poster