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

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

Структура директорий / The Directory Structure

Структура директорий песочницы отражает типовую и рекомендованную структуру приложения Symfony:

• hello/: Эта директория, названная по имени вашего приложения, содержит конфигурационные файлы;
• src/: Весь PHP код находится в этой директории;
• web/: Это директория web root.

Директория web / The Web Directory

Корень веб – это домашняя директория для всех публичных и статических файлов типа изображений, стилей и javascript-файлов. Она также содержит боевой фронт-контроллер:

# web/index.php
<?php

require_once __DIR__.'/../hello/HelloKernel.php';

$kernel = new HelloKernel('prod', false);
$kernel->run();

Как и любой другой фронт-контроллер, index.php использует Kernel Class, HelloKernel, для инициализации и запуска приложения.

Директория приложения / The Application Directory

Класс HelloKernel это главная точка входа  в настройки приложения и он хранится в директории hello/.

Этот класс должен реализовывать 5 методов:

• registerRootDir(): Возвращает корневую директорию;
• registerBundles(): Возвращает массив всех пакетов (бандлов) нобходимых для запуска приложения (обратите внимание на ApplicationHelloBundleBundle);
• registerBundleDirs(): Возвращает массив ассоциаций пространств имен и их домашних директорий;
• registerContainerConfiguration(): Возвращает главный конфигурационный объект (об этом подробнее ниже);
• registerRoutes(): Возвращает конфигурацию маршрутизатора.

Обратите внимание на дефолтную реализацию этих методов для того чтобы лучше понять гибкость фреймворка. В начале этого руководства вы открывали файл hello/config/routing.yml. Этот путь был сконфигурирован в методе registerRoutes():

public function registerRoutes()
{
  $loader = new RoutingLoader($this->getBundleDirs());

  return $loader->load(__DIR__.'/config/routing.yml');
}

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

Для того чтобы это все работало, ядро подключает два файла из директории src/:

# hello/HelloKernel.php
require_once __DIR__.'/../src/autoload.php';
require_once __DIR__.'/../src/vendor/symfony/src/Symfony/Foundation/bootstrap.php';

Директория исходных кодов / The Source Directory

Файл src/autoload.php отвечает за автозагрузку всех файлов из директории src/:

# src/autoload.php
require_once __DIR__.'/vendor/symfony/src/Symfony/Foundation/UniversalClassLoader.php';

use SymfonyFoundationUniversalClassLoader;

$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
  'Symfony'     => __DIR__.'/vendor/symfony/src',
  'Application' => __DIR__,
  'Bundle'      => __DIR__,
  'Doctrine'    => __DIR__.'/vendor/doctrine/lib',
));
$loader->registerPrefixes(array(
  'Swift_' => __DIR__.'/vendor/swiftmailer/lib/classes',
  'Zend_'  => __DIR__.'/vendor/zend/library',
));
$loader->register();

// for Zend Framework & SwiftMailer
set_include_path(__DIR__.'/vendor/zend/library'.PATH_SEPARATOR.__DIR__.'/vendor/swiftmailer/lib'.PATH_SEPARATOR.get_include_path());

Класс UniversalClassLoader используется для автозагрузки файлов, которые удовлетворяют либо техническому стандарту для пространств имен в PHP 5.3 или же соглашению о наименовании классов PEAR. Как вы можете видеть, все зависимости хранятся в директории vendor/, но, это всего-лишь соглашение. Вы можете хранить их где вам удобно, глобально на сервере или локально в вашем проекте.

Еще немного о пакетах / More about Bundles

Как мы могли видеть в предыдущей части, приложение состоит из пакетов, определенных в методе registerBundles():

# hello/HelloKernel.php
public function registerBundles()
{
  return array(
    new SymfonyFoundationBundleKernelBundle(),
    new SymfonyFrameworkWebBundleBundle(),
    new SymfonyFrameworkDoctrineBundleBundle(),
    new SymfonyFrameworkSwiftmailerBundleBundle(),
    new SymfonyFrameworkZendBundleBundle(),
    new ApplicationHelloBundleBundle(),
  );
}

Но как же Symfony понимает где искать пакеты? Symfony очень гибок в этом отношении. Метод registerBundleDirs() должен возвращать ассоциативный массив, который ставит в соответствие пространству имен некоторую валидную директорию (локальную или глобальную):

public function registerBundleDirs()
{
  return array(
    'Application'        => __DIR__.'/../src/Application',
    'Bundle'             => __DIR__.'/../src/Bundle',
    'Symfony\Framework' => __DIR__.'/../src/vendor/symfony/src/Symfony/Framework',
  );
}

Итак, когда вы ссылаетесь на HelloBundle в имени контроллера или в имени шаблона, Symfony будет искать его в указанных директориях.

Ну как, вы поняли почему Symfony такой гибкий? Используйте ваши пакеты в различных приложениях, храните их локально или глобально на ваш выбор.

Вендоры / Vendors

Часто ваше приложение будет зависеть от сторонних библиотек. Они должны храниться в директории src/vendor/. Она уже содержит библиотеки Symfony – SwiftMailer, Doctrine ORM, и избранное из классов Zend Framework.

Кэш и логи / Cache and Logs

Symfony это один из самых быстрых фреймворков. Но как он может быть таким быстрым, если он постоянно должен парсить и интерпретировать десятки YAML и XML файлов? Частично это обязанность системы кеширования. Конфигурация приложения парсится только для первого запроса и после этого компилируется в обычный PHP код, который хранится в директории приложения cache/. В девелоперском окружении Symfony сбрасывает кэш когда вы изменяете файл, но в продуктовом окружении это уже ваша обязанность чистить кэш, когда вы обновляете ваш код или конфигурацию.

Во время разработки web-приложения что-то может пойти не так в любой момент. Файлы логов в директории приложения logs/ могут рассказать вам подробности о запросах и помочь разобраться в проблеме, не затратив много времени.

Интерфейс командной строки / The Command Line Interface

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

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

$ php hello/console

Опция --help поможет вам уточнить способ использования любой команды:

$ php hello/console router:debug --help

Последний рывок / Final Thoughts

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

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

Источник: http://symfony-reloaded.org/quick-tour-part-5

P.S. На текущий момент, увы, на официальном сайте проекта следующей главы, на которую ссылается автор, пока нет. Так что пока повременим становиться мастерами симфонии (ваш hudson).

• Symfony 2.0 – быстрый тур – общая картинка (часть 1)
• Symfony 2.0 – быстрый тур – вид/the view (часть 2)
• Symfony 2.0 – быстрый тур – контроллер/the controller (часть 3)
• Symfony 2.0 – быстрый тур – архитектура/the architecture (часть 5)

Система пакетов / The Bundle System

Пакеты в Symfony можно сравнить с модулями расширений (плагинами) в прочем программном обеспечении. Но почему же тогда мы кошку называем кошкой пакет называем пакетом а не плагином? А потому что в Symfony все есть пакет: начиная от ядра фремворка и заканчивая кодом, который вы пишите для своего приложения. Пакеты – это граждане первейшего сорта. Они дают вам гибкость в использовании возможностей сторонних пакетов или же распространении своих собственных пакетов. Т.о. вы можете легко выбирать какие возможности будут доступны вашему приложению и оптимизировать его требуемым вам способом.

Приложение состоит из пакетов, определенных в методе registerBundles() класса HelloKernel:

# hello/HelloKernel.php
public function registerBundles()
{
  return array(
    new SymfonyFoundationBundleKernelBundle(),
    new SymfonyFrameworkWebBundleBundle(),
    new SymfonyFrameworkDoctrineBundleBundle(),
    new SymfonyFrameworkSwiftmailerBundleBundle(),
    new SymfonyFrameworkZendBundleBundle(),
    new ApplicationHelloBundleBundle(),
  );
}

Обратите внимание, что наряду с HelloBundle, ядро подключает KernelBundle, WebBundle, DoctrineBundle, SwiftmailerBundle и ZendBundle. Все эти пакеты являются частью ядра фреймворка.

Каждый пакет может быть настроен через конфигурационные файлы, написанные на YAML или XML. Давайте взглянем на конфигурацию по-умолчанию:

# hello/config/config.yml
kernel.config: ~
web.web: ~
web.templating: ~

Каждый параметр, например kernel.config определяет конфигурацию пакета. Некоторые пакеты могут иметь много настроек если вы используете много возможностей, например WebBundle имеет две настройки: web.web и web.templating.

Каждое окружение может переопределять конфигурацию по-умолчанию через отдельные конфигурационные файлы:

# hello/config/config_dev.yml
imports:
  - { resource: config.yml }

web.debug:
  exception: %kernel.debug%
  toolbar:   %kernel.debug%

zend.logger:
  priority: info
  path:     %kernel.root_dir%/logs/%kernel.environment%.log

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

Пользователь / The User

Не смотря на то что протокол HTTP не сохраняет состояния между запросами, Symfony предоставляет отличный объект user, который представляет клиента (будь то реальный человек через интернет-обозреватель, бот или же вебсервис). Между двумя запросами Symfony сохраняет атрибуты в cookie с использованием нативных сессий PHP.

Эта возможность предоставляется WebBundle и может быть подключена при помощи следующей строки в config.yml:

# hello/config/config.yml
web:user: ~

Сохранение и получение информации о пользователе осуществляется следующим образом:

// store an attribute for reuse during a later user request
$this->getUser()->setAttribute('foo', 'bar');

// in another controller for another request
$this->getUser()->getAttribute('foo');

// get/set the user culture
$this->getUser()->setCulture('fr');

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

$this->getUser()->setFlash('notice', 'Congratulations, your action succeeded!')

Работа с БД / Accessing the Database

Если ваш проект взаимодействует с базой данных тем или иным образом, вы свободны в выборе любого удобного вам инструмента. Вы можете использовать ORM, например Doctrine или Propel, если хотите высокого уровня абстракции от БД. Но в этой секции мы не будем усложнять примеры и воспользуемся Doctrine DBAL, который представляет собой “тонкий слой” поверх PDO, для подключения к базе данных.

Подключим DoctrineBundle и сконфигурируем наше подключение в config.yml:

# hello/config/config.yml
doctrine.dbal:
  driver:   PDOMySql # can be any of OCI8, PDOMsSql, PDOMySql, PDOOracle, PDOPgSql, or PDOSqlite
  dbname:   your_db_name
  user:     root
  password: your_password # or null if there is none

Вот и все. Теперь вы можете использовать объект соединения для взаимодействия с БД из любого действия:

public function showAction($id)
{
  $stmt = $this->getDatabaseConnection()->execute('SELECT * FROM product WHERE id = ?', array($id));

  if (!$product = $stmt->fetch())
  {
    throw new NotFoundHttpException('The product does not exist.');
  }

  return $this->render(...);
}

Выражение $this->getDatabaseConnection() возвращает объект, с которым можно работать как и с PDO.

Отправка email / Sending Emails

Отправить email в Symfony также просто как и щелкнуть пальцами. Во-первых, нужно подключить SwiftmailerBundle и сконфигурировать его:

# hello/config/config.yml
swift.mailer:
  transport: gmail # can be any of smtp, mail, sendmail, or gmail
  username:  your_gmail_username
  password:  your_gmail_password

После этого вы можете использовать мэйлер в любом действии:

public function indexAction($name)
{
  // get the mailer first (mandatory to initialize Swift Mailer)
  $mailer = $this->getMailer();

  $message = Swift_Message::newInstance()
    ->setSubject('Hello Email')
    ->setFrom('send@example.com')
    ->setTo('recipient@example.com')
    ->setBody($this->renderView('HelloBundle:Hello:email', array('name' => $name)))
  ;
  $mailer->send($message);

  return $this->render(...);
}

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

Последний рывок / Final Thoughts

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

Оригинал: http://symfony-reloaded.org/quick-tour-part-4

• Symfony 2.0 – быстрый тур – общая картинка (часть 1)
• Symfony 2.0 – быстрый тур – вид/the view (часть 2)
• Symfony 2.0 – быстрый тур – пакеты/the bundles (часть 4)
• Symfony 2.0 – быстрый тур – архитектура/the architecture (часть 5)

Форматы / Formats

Современное web-приложение должно доставлять пользователю больше чем просто HTML-страницы. Тип контента может варьироваться от XML для RSS ил web-сервисов до JSON для Ajax-запросов. Есть множество различных форматов на любой вкус и случай жизни. Symfony имеет встроенную поддержку этих форматов. Отредактируйте routing.yml и добавьте _format создначением xml:

# src/Application/HelloBundle/Resources/config/routing.yml
hello:
  pattern:  /hello/:name
  defaults: { _bundle: HelloBundle, _controller: Hello, _action: index, _format: xml }

Затем, добавьте шаблон index.xml.php рядом с index.php:

# src/Application/HelloBundle/Resources/views/Hello/index.xml.php
<hello>
  <name><?php echo $name ?></name>
</hello>

Вот и все что нужно сделать. Не требуется даже менять контроллер. Для стандартных форматов Symfony автоматически выберет лучший заголовок content-type для ответа. Если вы хотите поддерживать различные форматы в одном действии (action), используйте :_format в настройке маршрута:

# src/Application/HelloBundle/Resources/config/routing.yml
hello:
  pattern:      /hello/:name.:_format
  defaults:     { _bundle: HelloBundle, _controller: Hello, _action: index, _format: html }
  requirements: { _format: (html|xml|json) }

Контроллер теперь будет вызываться для URL вида: /hello/Fabien.xml или для /hello/Fabien.json. В качестве значения по умолчанию для _format используется html, /hello/Fabien и /hello/Fabien.html оба используют HTML формат.

Требования (requirements) определяют регулярное выражение, которому переменная для подстановки (placeholder) должна соответствовать. В этом примере, если вы захотите вызвать /hello/Fabien.js вы получите ошибку HTTP 404, так как запрос не соответствует требованиям маршрута.

Объект ответа / The Response Object

Давайте теперь вернемся к контроллеру Hello:

public function indexAction($name)
{
  return $this->render('HelloBundle:Hello:index', array('name' => $name));
}

Метод render() осуществляет отображение шаблона и возвращает объект Response. Ответ сервера может быть донастроен перед его отправкой клиенту, например, можно изменить Content-type:

public function indexAction($name)
{
  $response = $this->render('HelloBundle:Hello:index', array('name' => $name));
  $response->setHeader('Content-Type', 'text/plain');

  return $response;
}

Для простейших шаблонов вы даже можете создавать объект Response вручную и сэкономить этим несколько милисекунд:

public function indexAction($name)
{
  return $this->createResponse('Hello '.$name);
}

Чаще всего это имеет смыл применять, например, для JSON-содержимого, что, в свою очередь, может быть использовано для Ajax-запросов.

Управление ошибками / Error Management

Когда что-то не может быть найдено, вы должны вернуть ошибку 404. Это легко сделать, вызвав специальное HTTP исключение:

use SymfonyComponentsRequestHandlerExceptionNotFoundHttpException;

public function indexAction()
{
  $product = // retrieve the object from database
  if (!$product)
  {
    throw new NotFoundHttpException('The product does not exist.');
  }

  return $this->render(...);
}

NotFoundHttpException вернет в браузер ответ с ошибкой 404. Похожим образом действует и исключение ForbiddenHttpException, которое возвращает ошибку 403 и UnauthorizedHttpException, которое возвращает ошибку 401. Для других кодов ошибок вы можете использовать базовый класс  HttpException и передавать код ошибки в качестве кода исключения:

throw new HttpException('Unauthorized access.', 401);

Перемещения и перенаправления / Redirecting and Forwarding

Если вы хотите переместить пользователя на другую страницу, вы можете использовать метод redirect().

$this->redirect($this->generateUrl('hello', array('name' => 'Lucas')));

Метод generateUrl здесь – это такой же метод, как и generate(), который мы использовали в хелпере маршрутизации ранее. Он принимает в качестве аргументов наименование маршрутов и массив параметров, на основе чего возвращает дружественный URL. Вы также легко можете перенаправить одно действие на другое при помощи метода forward(). Как и хелпер $view-actions, он выполняет внутренний подзапрос, но он возвращает объект  Response, который при необходимости можно изменять:

$response = $this->forward('HelloBundle:Hello:fancy', array('name' => $name, 'color' => 'green'));

// do something with the response or return it directly

Объект запроса / The Request Object

Кроме значений подстановки (placeholders) из маршрутов, контроллер также имеет доступ к объекту запроса Request:

$request = $this->getRequest();

$request->isXmlHttpRequest(); // is it an Ajax request?

$request->getPreferredLanguage(array('en', 'fr'));

$request->getQueryParameter('page'); // get a $_GET parameter

$request->getRequestParameter('page'); // get a $_POST parameter

В шаблоне вы также можете получить доступ к объекту запроса через хелпер request:

<?php echo $view->request->getParameter('page') ?>

Последний рывок / Final Thoughts

Вот и все, что хотелось рассказать, и я даже не уверен, что мы использовали все 10 минут )) В предыдущей части мы видели, как можно расширить систему шаблонов при помощи хелперов. Расширение возможностей контроллеров может быть легко достигнуто благодаря пакетам (bundles). Но это уже тема для нашего следующего разговора!

Оригинал: http://symfony-reloaded.org/quick-tour-part-3

• Symfony 2.0 – быстрый тур – общая картинка (часть 1)
• Symfony 2.0 – быстрый тур – контроллер/the controller (часть 3)
• Symfony 2.0 – быстрый тур – пакеты/the bundles (часть 4)
• Symfony 2.0 – быстрый тур – архитектура/the architecture (часть 5)

Декорирование шаблонов

Очень часто, шаблоны в проектах используют общие элементы, например всем известные хидер (header) и футер (footer). В Symfony мы имеем по этому поводу свое мнение: шаблон может быть декорирован другим шаблоном. Давайте посмотрим на файл layout.php:

# src/Application/HelloBundle/Resources/views/layout.php
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  </head>
  <body>
    <?php $view->slots->output('_content') ?>
  </body>
</html>

Шаблон index декорируется шаблоном layout.php (спасибо extend()):

# src/Application/HelloBundle/Resources/views/Hello/index.php
<?php $view->extend('HelloBundle::layout') ?>

Hello <?php echo $name ?>!

Нотация HelloBundle::layout звучит знакомо, не так ли? Это та же самая нотация для привязки шаблона. Часть “::” означает что контроллер пуст (не указан) и следовательно соответствующий файл хранится напрямую во views/.

Строка $view->slots->output(‘_content’) заменяется контентом дочернего шаблона, index.php (про него подробнее в следующей секции).

Как вы можете видеть, Symfony предоставляет метод загадочного объекта $view. В шаблоне, $view это специальный объект, который предоставляет пачку методов и свойств, которые заставляют движок шаблонов “тикать как часы”.

Symfony также поддерживает множественные уровни декорации (multiple decoration levels): один layout может быть декорирован другим. Эта техника будет полезна для больших проектов и она становится еще более могущественной в комбинации со слотами (slots).

Слоты.

Что есть слот? Слот – это кусочек кода, определенный в шаблоне, который может быть использован в любом макете (layout), декорирующем шаблон. Определим слот title в шаблоне index:

# src/Application/HelloBundle/Resources/views/Hello/index.php
<?php $view->extend('HelloBundle::layout') ?>

<?php $view->slots->set('title', 'Hello World app') ?>

Hello <?php echo $name ?>!

И изменим макет таким образом, чтобы title выводился в заголовке:

# src/Application/HelloBundle/Resources/views/layout.php
<html>
  <head>
    <title><?php $view->slots->output('title', 'Default Title') ?></title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  </head>
  <body>
    <?php $view->slots->output('_content') ?>
  </body>
</html>

Метод output() вставляет содержимое слота и опционально принимает значение по умолчанию, если слот не установлен. Также, _content является специализированным слотом, который содержит отрендереный шаблон дочернего шаблона.

Для больших слотов также есть расширенный синтаксис:

<?php $view->slots->start('title') ?>
  Some large amount of HTML
<?php $view->slots->stop() ?>

Подключение других шаблонов.

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

Создадим шаблон hello.php:

# src/Application/HelloBundle/Resources/views/Hello/hello.php
Hello <?php echo $name ?>!

И изменим шаблон index.php чтобы подключить его:

# src/Application/HelloBundle/Resources/views/Hello/index.php
<?php $view->extend('HelloBundle::layout') ?>

<?php echo $view->render('HelloBundle:Hello:hello', array('name' => $name)) ?>

Метод render() вычисляет и возвращает содержимое другого шаблона (это точно такой же метод, который используется в контроллере).

Встраивание других действий

А что, если вы хотите отобразить результат другого действия в шаблоне? Это очень нужно при работе с Ajax или когда встраиваемый шаблон требует переменные, которые не определены в основном шаблоне.

Если вы создадите действие fancy и захотите включить его в шаблон шndex, просто используйте следующий код:

# src/Application/HelloBundle/Resources/views/Hello/index.php
<?php $view->actions->output('HelloBundle:Hello:fancy', array('name' => $name, 'color' => 'green')) ?>

Здесь, строка HelloBundle::Hello::fancy ссылается на действие fancy контроллера Hello:

# src/Application/HelloBundle/Controller/HelloController.php
class HelloController extends Controller
{
  public function fancyAction($name, $color)
  {
    // create some object, based on the $color variable
    $object = ...;

    return $this->render('HelloBundle:Hello:fancy', array('name' => $name, 'object' => $object));
  }

  // ...
}

Вы также должны иметь в виду, что эта техника очень мощная, но в то же время медленная, так как она порождает внутренний подзапрос (sub-request). Таким образом, везде где возможно – применяйте более быструю альтернативу.

Но где же определено свойство $view->actions? Как и $view->slots, оно вызывает хелпер шаблона и в следующей секции в узнаете об этом чуть больше!

Хэлперы шаблонов

Система шаблонов Symfony может быстро и просто быть расширена через хелперы. Хелперы это PHP объекты, которые предоставляют функционал, который требуется в шаблонах. actions и slots это лишь два, встроенных в Symfony, хелперов.

Линки(связи) между страницами

Говоря о веб-приложениях, вы должны всегда создавать ссылки между различными страницами. Вместо того чтобы хардкодить URL в шаблоне, хэлпер маршрутов (router helper) знает как создать URL, основываясь на конфигурации маршрутов. Таким образом, все URL могут быть легко и непринужденно изменены через конфигурацию.

<a href="<?php echo $view->router->generate('hello', array('name' => 'Thomas')) ?>">
  Greet Thomas!
</a>

Метод generate() принимает имя маршрута и массив аргументов. Имя маршрута это основной ключ, по которому маршрут можно найти и аргументы как минимум должны покрывать метки-плейсхолдеры в описании маршрута.

# src/Application/HelloBundle/Resources/config/routing.yml
hello: # The route name
  pattern:  /hello/:name
  defaults: { _bundle: HelloBundle, _controller: Hello, _action: index }

Использование ассетов (картинки, стили, скрипты)

Каким бы был интернет без картинок, скриптов и стилей? Symfony предлагает три хелпера для упрощения работы с ними: assets, javaScripts и stylesheets.

<link href="<?php echo $view->assets->getUrl('css/blog.css') ?>" rel="stylesheet" type="text/css" />

<img src="<?php echo $view->assets->getUrl('images/logo.png') ?>" />

Назначение хелпера assets – сделать ваше приложение более переносимым (portable). Благодаря ему, вы можете переносить корень приложения куда вам угодно в рамках directory root без изменений в коде ваших шаблонов.

Таким же образом вы можете управлять стилями и яваскриптами при помощи хелперов stylesheets и javaScripts:

<?php $view->javascripts->add('js/product.js') ?>
<?php $view->stylesheets->add('css/product.css') ?>

Метод add() определяет зависимости. Для вывода ассетов вам нужно добавить следующий код в основной шаблон (layout):

<?php echo $view->javascripts ?>
<?php echo $view->stylesheets ?>

Последний рывок

Система шаблонов Symfony простая, но очень эффективная. Благодаря layot’ам, slot’ам, шаблонам и включению действий очень легко можно организовать ваши шаблоны логично и гибко. Позднее вы узнаете как конфигурировать поведение по умолчанию для шаблонизатора и как расширять ее, добавляя новые хелперы.

Итого, мы провели с Symfony что-то около 20 минут и вы уже можете делать много интересных вещей. Это сила Symfony. Изучить основы легко, но скоро вы поймете, что эта простота скрывает очень гибкую архитектуру.

Но не будем забегать вперед. Для начала вам нужно изучить немного больше о контроллере и это будет темой нашего следующего занятия. Готовы выделить еще 10 минут для Symfony?

Оригинал взят тут: http://symfony-reloaded.org/quick-tour-part-2