Введение в Symfony Framework основы


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

Введение

Сразу хочу отметить, что статья не тянет на учебное пособие или руководсво для новичков в PHP, потому что фреймворк досточно сложный, но интересный (: Как говориться, путь осилит идущий.

Что же нам дает использование symfony?

Тут представлены основные возможности фреймворка, все их перечислять не имеет смысла, т.к. их очень много :)

  1. MVC архитектура WIKI page
  2. ORM Propel
  3. Специальные средства, упрощающие создание шаблонов страниц
  4. Управление многоуровневым кэшем (например, можно кэшировать разные части View)
  5. Наличие development и production среды (development/production environment). Причем их может быть несколько. Вы можете определить свою среду, несколько баз данных, настройки кеширования и др.
  6. Scaffolding — автоматически генерируемый модуль для управления содержимым таблицы из базы данных
  7. Человеко-Понятные URL (ЧПУ)
  8. Многоязычность (i18n) (языковый файлы храняться в xml файлах)
  9. Поддержка AJAX (по дефолту Propotype)
  10. Мне еще пондравилась дебаг панель, очень удобно просматривать запросы. Сейчас такие панели уже есть в большинстве фреймворков.

Из минусов можно заметить это достаточно долгое генерирование страниц при разработке, досточно большое потребление оперативы ~10-12МБ

оно и понятно, потому что при генерации подключаются ВСЕ классы, даже те которые может даже и не понадобятся на проекте.

+ сам вес фреймворка не редко приближается к достаточно большим размерам.

Софт

Вы можете сказать, типо «это же PHP, что тут требуется особый софт?». Конечно, нет. Можно открывать файлы даже тем же блокнотом, но тогда ваша работа не будет продуктивной. Лучше всего использовать специализированные IDE, которые помогут лучше работать с проектом, да и это правильно имхо. Я рекомендую: 1. Zend studio for eclipce + symfony plugin 2. Eclipce c плагином для symfony 3. PHPEdit еще одна IDE c поддежкой симфони. С последней я познакомился относительно недавно, но юзаю попрежнему Zend studio for eclipce.

А если ли уже готовые CMS на symfony?

Да, есть! Проекто этот называется SteerCMS. В CMS уже идет куча модулей, есть несколько собственных шаблонов для сайта. Админка чем то напоминает знаменитый Wordpress. Хороший проект, но видимо разработчики его зарбосили, к сожелению. Эту CMS не комендуется использовать для реальных проектов или самому доводить в более мение работоспособное состояние. У меня эта CMS завелась со второго раза)

Установка Symfony

Самый простой способ — использовать пакет PEAR. Сразу замечу, что это не очень хороший способ, так как можно легко запутаться и так не установить фреймворк. Если кто хочет всеже попробовать пойти этим путем рекомендую почитать эту заметку. Symfony — PHP5 MVC Фреймворк Там довольно хорошо описана установка symfony как и из PEAR так и из Sandbox.но мы же не ищем легких путей?)

Дальше описывает начало проекта и основные конфигурационные файлы. Описание БОЛЬШЕЙ частью взято с офф сайта, т.к. нет смысла придумывать велосипед.

Более подробное описание читайте на офф сайте:

Переведено далеко не все, но для создание простого сайта этого хватит с лихвой. Дерзайте.

Установка проекта

В symfony приложения имеющие общие модели данных выносятся в проекты. В проекте «askeet» будет реализованы backend(админка) и frontend(сам сайт) — это 2 приложения. Проект является основой приложений и должен быть создан первым. Всё что вам нужно это папка проекта и коммандная строка:

$ mkdir /home/sfprojects/askeet
$ cd /home/sfprojects/askeet
$ symfony init-project askeet

Пора создать frontend для symfony:

$ symfony init-app frontend

Конфигурация приложения

Главная часть настроек это настройки приложения. Основные константы определены в фронт-контроллере (он находится в директории web/), опции для файлов интернационализации содержатся в YAML файлах директории i18n/, остальные настройки — в директории config/. Также дополнительные, скрытые, но полезные для приложения настройки, заданы в файлах фреймворка.

Настройки фронт-контроллера

Самые главные настройки приложения находятся в фронт-контроллере; это первый скрипт, который выполняется при запросе (request). Взгляните на стандартный web/index.php

define('SF_ROOT_DIR',    dirname(__FILE__).'/..');
define('SF_APP',         'myapp');
define('SF_ENVIRONMENT', 'prod');
define('SF_DEBUG',       true);require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.'apps'.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.'config'.DIRECTORY_SEPARATOR.'config.php');

sfContext::getInstance()->getController()->dispatch();

После задания имени приложения (myapp) и среды (prod), но до передачи обработки запроса дальше, вызывается основной конфигурационный файл, в котором заданы несколько полезных констант:

  • SF_ROOT_DIR: Корневая директория проекта (Этот параметр обычно должен равняться значению по умолчанию, если вы не хотите менять файловую структуру).
  • SF_APP: Имя приложения в проекте. Необходимо для составления путей.
  • SF_ENVIRONMENT: Название среды (environment). Может быть prod, dev, или любым другим, заданным вами. Этот параметр определяет, какой набор настроек нужно использовать.
  • SF_DEBUG: Опция активирующая режим отладки (debug mode).

Только файлы и скрипты из веб директории (в symfony это папка web/) доступны извне. Там находятся скрипты фронт-контроллеров, изображения, таблицы стилей, и яваскрипты. Все остальные файлы не должны находиться в веб директории — это значит, что они могут находиться в любом другом месте. Фронт-контроллер обращается к ненаходящимся в свободном доступе файлам через путь SF_ROOT_DIR. Традиционно, корневая директория находится уровнем выше от директории web/. Но вы можете выбрать совершенно другую структуру. Представим, что файловая структура состоит из двух директорий, одна с открытым доступом и другая с закрытым:

symfony/    # Закрытый доступ
apps/ - папка контроллеров (фронт, админ)
config/ - файла конфигурации
cache/ - кеш
plugins/ - плагины
lib/  - ядро (папка с библиотеками и сгенерироваными либами)
...
www/        # Открытый доступ
images/
css/
js/
index.php

В этом случае symfony/ — корневая директория. Поэтому в фронт-контроллере index.php параметр SF_ROOT_DIR задан следующим образом:

define('SF_ROOT_DIR', dirname(__FILE__).'/../symfony');

Основные настройки приложения

Основные настройки приложения находятся в файлах директории

myproject/apps/myapp/config/:

Файлы в папке:

  • app.yml: Этот файл содержит настройки специфические для данного приложения; это глобальные переменные, используемые в бизнес логике и логике приложения, которые нет нужды хранить в базе данных. В этом файле часто хранятся налоговые ставки, цены на доставку, e-mail адреса. По умолчанию он пустой.
  • config.php: Этот файл отвечает за начальную загрузку приложения, это означает, что в нем происходят все основные инициализации необходимые для начала работы приложения. Тут вы можете изменять файловую структуру, или добавить специфические для данного приложения константы. В начале файла подключается (include) config.php проекта.
  • factories.yml: Symfony предоставляет свои собственные классы для обработки view, запроса (request), ответа (response), сессии (session), и т. д. Если вы желаете использовать свои собственные классы, то нужно определить их в этом файле.
  • filters.yml: Фильтры это куски кода, выполняемые при каждом запросе (request). В этом файле можно задать какие фильтры необходимо использовать. Эти настройки могут быть перезаданы на уровне модуля.
  • logging.yml: В этом файле можно задать уровень детализации для журналов событий (log), чтоб облегчить управление приложением и отладку.
  • routing.yml: Здесь хранятся правила роутинга, благодаря которым обеспечивается трансформация нечитаемых и неудобных для добавления в закладки (unbookmarkable) URL в говорящие сами за себя ЧПУ(человеко-понятные-урл) адреса. В новом приложении по умолчанию существует несколько правил.
  • settings.yml: Основные настройки приложения symfony содержатся в этом файле. Тут вы можете задать многоязычно приложение или нет, язык используемый по умолчанию, время ожидания запроса (request timeout), включен ли кэш. Изменением одной строки вы можете прекратить работу приложения, чтоб заняться технической поддержкой или обновить (upgrade) какой-то компонент.
  • view.yml: Структура view по умолчанию (имя главного шаблона (layout), заголовок (title), теги meta; стандартные таблицы стилей и подключаемые яваскрипты; тип контента по умолчанию, и т. д.) задаются в этом файле. Тут также определяются значения по умолчанию для тегов title и meta. Эти установки могут быть перезаданы для каждого модуля.
  • i18n.yml в директории приложения config/: Этот файл задает основные опции перевода, такие как, используемая по умолчанию для перевода культура (default culture), хранятся переводы в базе данных или в файлах.
  • Файлы переводов в директории приложения i18n/: Это в основном словари, которые предоставляют перевод для каждой фразы, используемой в шаблонах приложения. С помощью них на страничке выводится переведенный текст при переключении языка.

Дополнительные настройки приложения

Еще один набор конфигурационных файлов находится в установочной директории symfony ($sf_symfony_data_dir/config/). Находящейся в них опции либо определены по умолчанию, и потребность изменять их возникает редко, либо общие для всех проектов. Однако, если вы пожелайте изменить эти настройки, просто создайте пустой файл с таким же именем в вашей директории myproject/apps/myapp/config/ и перезадайте в нем нужные опции. Заданные на уровне приложения настройки имеют больший приоритет, чем настройки определенные в фреймворке. Вот список конфигурационных файлов директории config/ фреймворка:

  • autoload.yml: Файл содержит опции автоподключения. Эта возможность позволит не подключать пользовательские классы в вашем коде, если они находятся в специальных директориях.
  • constants.php: Этот файл задает файловую структуру приложения по умолчанию. Чтоб перезадать ее, используйте config.php приложения.
  • core_compile.yml и bootstrap_compile.yml: Это списки классов, которые нужно подключить для запуска приложения (bootstrap_compile.yml) и для обработки запроса (core_compile.yml). В действительности, эти файлы объединены в один оптимизированный PHP файл без комментариев, который ускоряет работу, минимизируя количество операций доступа к файлу. Это в особенности удобно, если вы не используйте PHP акселератор.
  • config_handlers.yml: Тут вы можете поменять обработчик (handler) для каждого конфигурационного файла.
  • php.yml: Этот файл проверяет правильно ли заданы переменные php.ini и также позволяет перезадать их, если это необходимо.

Настройки модуля

По умолчанию модуль не имеет собственных настроек. Но, если возникнет необходимость, вы можете перезадать некоторые опции приложения для данного модуля. К примеру, можно переопределить параметры используемые в HTML только для всех действий (action) данного модуля, или подключить какой-то специфический яваскрипт. Вы также можете задать новые параметры, доступные только в данном модуле, таким образом обеспечив инкапсуляцию. Как вы уже наверное догадались, настройки модуля содержатся в директории

myproject/apps/myapp/modules/mymodule/config/

Вот список файлов:

  • generator.yml: Этот файл нужен для сгенерированных на основе таблицы базы данных модулей. Тут определяется, как будут отображаться строки и поля, какие действия будут доступны пользователю (фильтры, сортировка, кнопки, и т. д.).
  • module.yml: Тут содержатся пользовательские параметры индивидуальные для данного модуля (эквивалент app.yml, но на уровне модуля) и некоторые настройки действия (action).
  • security.yml: Файл определяет ограничения доступа. Тут можно разрешить доступ к модулю только для зарегистрированных пользователей или для какой-то подгруппы зарегистрированных пользователей, имеющих специальные права.
  • view.yml: Настройки view хранятся здесь. Они могут быть заданы как для всех действий (action), так и индивидуально для каждого. Как обычно, эти опции имеют больший приоритет, чем опции заданные во view.yml приложения.
  • Файлы валидации данных: Несмотря на то, что они находятся в директории validate/, а не в config/, это тоже часть конфигурации модуля. Эти файлы используются для контроля над вводимыми через формы данными.

В большинстве случаев вам не понадобится менять настройки, поскольку опции по умолчанию соответствуют наиболее распространенным требованиям. Каждый файл соответствует какой-то конкретной возможности. Когда вы будете рассматривать один файл, вы четко увидите что он делает и как он организован. Для профессиональной веб разработки, настройки по умолчанию могут оказаться не совсем подходящими. Конфигурационные файлы позволяют легко изменять поведение механизмов symfony. Представьте сколько PHP кода необходимо чтоб достичь аналогичных возможностей контроля. Если все настройки были бы собраны в одном файле, файл не только был бы совершенно не читаемым, но и переопределить настройки на нескольких уровнях иерархии (проект/приложение/модуль) было бы невозможным. Конфигурационная система это одна из сильных сторон symfony. Благодаря ей на symfony можно создать почти любые веб приложения, а не только те для которых фреймворк изначально создавался.

Режимы (environments)

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

Environment — среда, режим Production environment (prod) — рабочая среда, рабочий режим, режим prod Development environment (dev) — среда разработки, режим разработки, режим dev Test environment (test)— среда тестирования, режим тестирования, режим test

По существу режим (environment) и конфигурация это синонимы. Например, в тестовом режиме в журнал событий заносится предупреждения (alert) и ошибки (error), а в рабочем режиме только ошибки. Зачастую в режиме разработки кэш не активирован, но в рабочем режиме и режиме тестирования кэш работает. Для режимов dev и test могут понадобиться тестовые данные, которые хранятся в базе отдельно от реальных данных, используемых в рабочем (prod) режиме. Поэтому и настройки базы данных для разных режимов будут разные. Все режимы (environment) могут находиться на одной машине, хотя на реальном сервере (production server) обычно содержится только рабочий режим (prod).

Установка веб-сервиса

Каждый разработчик настраивает свой web сервер под себя, тут можно лишь дать общие советы. Общее руководство можно почитать на офф сайте симфони: День 1: Начало проекта Откуда взята львиная доля материала для этой статьи.

Ссылки по теме

По материалам статей symfony-project.org