Feb 26

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

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

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

Собственно, всё начинается с создания проекта (project) и приложений (applications) в нем. Как это делается — можно почитать в книжке (ссылка приведена выше), а мне бы хотелось остановиться на обьяснении того, что такое проект и принципах выбора приложений в нем — какие им дать имена, как их структурировать и т.д.

Проект

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

Приложения

В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.

Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).

Сам я пользуюсь рекомендацией книги и имею два приложения в своем проекте.

Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.

Окружения (environments)

Останавливаться на окружениях особенно не хочется. Это очень удобный, но в то же время очень простой механизм, обеспечивающий возможность заходить в одно и то же приложение с различными серверными настройками. Если сказать проще — представьте себе, что у вас есть приложения и галочка, которая переключает режим его работы в debug-mode и обратно. В debug-mode, например, все события логгируются, все ошибки выводятся на экран и т.д. Если же debug-mode выключен — все логи выключены, и на экране никогда никаких ошибок появляться не будет. Так вот — в Symfony вместо флага debug/не-debug имеется просто несколько различных окружений, каждое из которых можно настроить ПОЛНОСТЬЮ, т. е. не система решает — что включить, а что выключить, а вы сами. Хочется также отметить, что особо копаться в настройках вам не прийдется — по умолчанию для каждого приложения создается 3 environment’а: production, development, testing (используется исключительно при тестировании).

В общем, тут придраться не к чему — всё, на мой взгляд, просто идеально.

Модули (modules)

… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.

Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.

Последнее, на чем хотелось бы остановиться — это…

Модели (models)

Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за 3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно.

Пожалуй, это всё, что может понадобиться новичку при изучении Symfony (чтобы она не казалась ему какой-то сложной и непонятной системой, какой она мне показалась год назад).

А вот теперь перейдем непосредственно к моим рекомендациям. Но перед этим я расскажу вам про…

Плагины (plugins)

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

  • конфигурационные файлы, в том числе свои модели (!!!)
  • модули
  • библиотеки

Я могу оказаться не прав, но как мне кажется, плагины — это такие себе мини-проекты, «всё в себе», чем выгодно отличаются от Symfony applications. На мой взгляд, ставку стоило делать в первую очередь на них — убрать приложения, а вместо них поставить плагины и создать некий инструмент, который бы позволил эти плагины связывать между собой.

Мои рекоммендации

  • В первую очередь — проектирование. Не скупитесь на этом шаге, анализируйте и уточняйте у заказчика непонятные пункты.
  • Видя перед собой (да хоть в уме) макет системы — продумайте, на какие части систему можно разбить.
  • Поищите среди существующих плагинов такие части (обязательно). Я в своем проекте использовал следующие плагины:
    • sfGuardPlugin — user management, security и т.д. Плагин - must have.
    • sfDateTimePlugin — очень удобная работа с датами и временем
    • sfPropelAlternativeSchemaPlugin — полезен при работе с плагинами, позволяет менять модели, прописанные в плагинах, не изменяя коды самих плагинов
    • sfPropelApprovableBehaviorPlugin — мне очень пригодился при «активации пользователей»
    • sfThumbnailPlugin — уменьшение картинок (не смотрите на название — с ресайзом 3MP-фотографий к 800×600 плагин справляется на отлично)
    • sfPropelActAsTaggableBehaviorPlugin — если вам нужны тэги
    • sfPropelActAsSluggableBehaviorPlugin — если вам нужны slug’и (а я советую их использовать — очень хорошо сказывается на читаемости url’ов, когда вместо id туда засовывать slug’и)
    • sfPropelActAsRatableBehaviorPlugin — рейтинги, довольно крутые, мне, к сожалению, не подошли…
    • sfPropelActAsCommentableBehaviorPlugin — всё, что нужно для комментариев
  • Используйте в работе автоматически генерируемые CRUD-модули и модули для админки

Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.

Давно у меня таких больших статей не было…

Запостил на Хабрахабр.

written by fxposter \\ tags: , , , ,

One Ping to “Symfony: как начать”

  1. Symfony и будущее этого блога » Блог FX'а Says:

    […] мне Symfony: как начать Feb […]


14 Responses to “Symfony: как начать”

  1. 1. vitex Says:

    Плюсанул на хабре. Если я уже долго работаю с Zend Framework и больше ни с чем, то хотя-бы дома стоит попрактиковаться с Symfony? Какие ещё книги посоветуеш?

  2. 2. FX Poster Says:

    Книги – никаких, кроме «The Definitive Guide to Symfony» я книг не знаю.

    Попрактиковаться определенно стоит. На самом деле Symfony представляет собой чистый каркас для разработки web-приложений. ZF же является, по сути, библиотекой, которую вполне можно использовать вместе с Symfony (например, для работы со сторонними сервисами).

  3. 3. mihailt Says:

    Отличная статья :)

  4. 4. Денис Радченко Says:

    Отличная статья. С начала разрывался между CI и CakePHP, теперь еще и Symfony добавилось

  5. 5. Igorekk Says:

    Спасибо, интересный пост, я взглянул на Symfony с точки зрения джангиста :)
    Посмотрел туториал на сайте – не понравилось как внедряется php-код в html. Поэтому вопрос: можно ли использовать какие-нибудь сторонние шаблонизаторы?

  6. 6. FX Poster Says:

    можно ли использовать какие-нибудь сторонние шаблонизаторы?
    Угу. Сейчас есть такие плагины:

  7. 7. Igorekk Says:

    Ага, спасибо… Хоть смарти можно – уже плюс :)

  8. 8. Виталий Says:

    В целом все так, но на счет того, что приложения и модули лишние, можно было бы обойтись одними плагинами, Вы не правы. Да, с помощью плагинов можно создавать переносимые из проекта в проект самостоятельные части. Но такие части проблематично тесно связать между собой. Приложения и модули тесно завязаны в пределах проекта, используют общую схему данных и модели, и это отличное свойство для серьезных проектов (для которых и создана symfony). А то, что хотите переносить пихайте в плагины. Если же хотите конструктор позволяющий легко создавать из готовых модулей целые порталы, используйте Joomla – замечательную CMS (инсталяция компонентов прямо из админки).

  9. 9. FX Poster Says:

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

  10. 10. broderix Says:

    Очень прошу помочь, начал изучать symfony, но я что-то делаю не так, не могу подключить ни один plugin, всегда ошибка:
    The component does not exist: “sfComment”, “commentList”

    По тотуриалу на symfony-prolect.com все получается, а по инструкциям на страницах плагинов – нет (http://trac.symfony-project.com/wiki/sfPropelActAsCommentableBehaviorPlugin)

    Объясните, почему надо указывать не существующие методы , к примеру:
    include_component(‘sfComment’, ‘commentList’, array(‘object’ => $post));
    упоминания ‘commentList’ нигде нет, та же как и об объекте ‘sfComment’.

    И еще вопрос: Как удалить application или module (тоже нигде не нашел) ?
    Спасибо.

  11. 11. FX Poster Says:

    Почитай внимательнее страничку плагина. Написано же: “If you want to take profit of the included comment module, you should also complete the following steps:” и так далее…

    Как удалить application или module (тоже нигде не нашел)
    А подумать? Посмотреть, что представляют собой сами приложения и модули? Модуль – просто удаляем соответствующую директорию, приложение – то же самое + php-файлы в /web/, которые относятся к соответствующему приложению.

  12. 12. Konstantin Mikhaylov Says:

    2FX Poster. Человек вообще-то сделал всё правильно. Я сам минут 30 сегодня потратил на разборку с этой проблемой.

    Оказалось, что там по дефолту приаттачена версия 0.10 плагина. В то время, как вся страница написана для версии 0.40. Потому нужно сначала вручную скачать с той страницы последнюю версию и поставить уже с диска этот плагин. Всё работает..

  13. 13. broderix Says:

    2 Konstantin Mikhaylov
    большое спасибо,
    убеждаюсь что нормальный спецов в новых технологиях мало все приходится изучать самому

  14. 14. FX Poster Says:

    Konstantin Mikhaylov
    The component does not exist: “sfComment”, “commentList”
    Это ошибка возникнет, если ты в enabled_modules не добавишь sfComment. И это явно написано на странице плагина. Вне зависимости от его версии.

    PS. У меня проблем с версиями не было, странно, что они у тебя появились.

    broderix
    Спецов не мало, спецов вполне достаточно. Но фраза “все приходится изучать самому” очень актуально. Тебе никто ничего объяснять не обязан, если хочешь научиться – учись. Тебе могут помочь, не более.

Leave a Reply