hudson@work » web разработка http://hudson.su статьи о web-разработке, менеджменте IT проектов и контроле качества Fri, 20 Jan 2012 13:15:39 +0000 en hourly 1 Хочешь свой фреймворк – их есть у меня!.. http://hudson.su/2012/01/05/how-to-create-own-framework-on-top-of-symfony2/ http://hudson.su/2012/01/05/how-to-create-own-framework-on-top-of-symfony2/#comments Thu, 05 Jan 2012 07:00:51 +0000 hudson http://hudson.su/?p=2189 … Сказал Фабиен Потенсье:

А зачем мне это надо – свой фреймворк?

Почему вам может захотеться создать ваш собственный фреймворк? Если вы оглядитесь вокруг – все будут вам говорить, что не стоит изобретать колесо, что вам лучше выбрать фреймворк из существующих и забыть про создание чего-то своего. И таки да, в основном они все правы, но я хочу вам предложить несколько причин, по котором стоит заняться созданием своего фреймворка. Итак, я хочу создать свой фреймворк чтобы:

  • Изучить низкоуровневую архитектуру современных web-фреймворков в общем и о Symfony2 в частности;
  • Создать фреймворк для некоторой особенной задачи (просто удостоверьтесь заранее, что ваша задача действительно особенная);
  • Провести эксперимент для удовольствия (метод учись-и-пробуй);
  • Провести рефакторинг старого/существующего приложения, которому нужен большой глоток современных практик web-разработки;
  • Доказать всем, что вы можете самостоятельно создать фреймворк (… ну может только слегка напрягшись)).

Пруф

UPDATE1: вторая часть статьи (работаем с компонентом Symfony2 HttpFoundation)

UPDATE2: третья часть статьи (Request & Response в действии)

UPDATE3: четвёртая часть статьи (подключаем Routing)

]]> http://hudson.su/2012/01/05/how-to-create-own-framework-on-top-of-symfony2/feed/ 0 Слайдкаст Игоря бондаренко с SQADays’10: тестирование защищенности веб приложений http://hudson.su/2011/12/06/slajdkast-igorya-bondarenko-s-sqadays10-testirovanie-zashhishhennosti-veb-prilozhenij/ http://hudson.su/2011/12/06/slajdkast-igorya-bondarenko-s-sqadays10-testirovanie-zashhishhennosti-veb-prilozhenij/#comments Tue, 06 Dec 2011 09:13:46 +0000 hudson http://hudson.su/?p=2153 Данный слайдкаст будет прежде всего полезен начинающим (а также более матёрым – которые ранее не сталкивались с тестированием безопасности) тестировщикам, а также веб-разработчикам начинающего уровня, чтобы понимать как их код будут ломать коллеги из QA, а также злодеи-анонимусы:

тестирование защищенности веб приложений
View more presentations from Zestranec

]]> http://hudson.su/2011/12/06/slajdkast-igorya-bondarenko-s-sqadays10-testirovanie-zashhishhennosti-veb-prilozhenij/feed/ 0 Symfony2 Глоссарий http://hudson.su/2011/03/28/symfony2-glossary/ http://hudson.su/2011/03/28/symfony2-glossary/#comments Mon, 28 Mar 2011 14:29:49 +0000 hudson http://hudson.su/?p=1863 Для того чтобы эффективно общаться между собой, люди (и программисты не исключение) заранее договариваются о некоторой базовой терминологии, поэтому перевод Symfony2 the Book, я хочу начать с небольшого глоссария, терминологию которого я буду использовать в дальнейшем.

Приложение (Application)

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

Пакет (Bundle)

Пакет, это директория, содержащая набор файлов (PHP, CSS, JavaScript, изображения), которые реализуют одну более-менее крупную функцию (блог, форум и т.д.). В Symfony2 всё (в основном) располагается внутри тех или иных пакетов. (The Bundle System)

Дистрибутив (Distribution)

Дистрибутив – это совокупность компонент Symfony2, выбранных пакетов, соответствующей структуры директорий, конфигурации по-умолчанию и опциональной системы конфигурирования. (Примечание: название “дистрибутив” показалось мне наиболее логичным в данном случае, слово конечно заимствованное, но в среде ИТ-шников все его знают, в то же время “дистрибьюция” – это уже что-то из мира продаж имхо).

Фронт-контроллер (Front Controller)

Фронт-контроллер, это короткий PHP-файл, который расположен в web-директории проекта. Обычно все запросы перехватываются фронт-контроллером, а основная его задача состоит в загрузке Symfony-приложения.

Спецификация протокола HTTP (HTTP Specification)

Спецификация протокола HTTP – это документ, который описывает протокол передачи гипертекста – набор правил, описывающих классическую клиент-серверную коммуникацию, базирующуюся на запросах и ответах. Спецификация определяет формат, используемый для запросов и ответов, а также всевозможные HTTP заголовки, которые каждый запрос/ответ могут иметь. За дополнительной информацией о протоколе HTTP вы можете обратиться по ссылкам: Http Wikipedia и HTTP 1.1 RFC.

Окружение (Environment)

Окружение это наименование (например prod или dev) совокупности параметров, которое соответствет некоторому набору конфигурационных параметров. Одно и то же приложение может быть запущено с использованием различных конфигураций посредством его запуска в различных окружениях. Это очень удобно, так как позволяет для одного приложения иметь dev[elopment] окружение для отладки и prod[uction] окружение, оптимизированное по скорости – для конечного пользователя.

Проект (Project)

Проект – это директория, состоящая из приложения, набора пакетов, сторонних библиотек, автозагрузчика и скрипта фронт-контроллера.

Служба (Service)

Служба – это базовый термин для любого объекта в PHP, который выполняет определнную задачу. Служба как правило используется глобально, например объект подключения к базе данных или объект для отправки email сообщений. О приложении, имеющим много независимых служб, говорят что оно реализует сервисно-ориентированную архитектуру.

Контейнер служб (Service Container)

Контейнер служб, также известный как Контейнер внедрения зависимости (Dependency Injection Container), это специальный объект, который управляет созданием экземпляров сервисов внутри приложения. Вместо того, чтобы создавать сервис напрямую, разработчик посредством конфигурации обучает контейнер служб как создавать тот или иной сервис. Контейнер служб в свою очередь позаботится о простом получении экземпляра службы и внедрения зависимых служб.
]]> http://hudson.su/2011/03/28/symfony2-glossary/feed/ 4 Symfony 2: конфигурирование пакетов http://hudson.su/2011/02/18/symfony-2-bundle-configuration/ http://hudson.su/2011/02/18/symfony-2-bundle-configuration/#comments Fri, 18 Feb 2011 08:27:05 +0000 hudson http://hudson.su/?p=1770 Для обеспечения большей гибкости, пакет (bundle) может содержать ряд конфигурационных настроек, используя встроенный механизм Symfony2.

Простая конфигурация

Для простой конфигурации можно воспользоваться разделом parameters, по-умолчанию присутствующим в конфигурации Symfony2. Параметры – это простые пары ключ-значение; значением может быть любое валидное значение с точки зрения PHP. Каждое наименование параметра должно начинаться с наименования пакета в нижнем регистре (hello для HelloBundle, или sensio.social.blog для SensioSocialBlogBundle).

Пользователь может задавать значения в любом конфигурационном файле:

  • YAML 
    # app/config/config.yml
parameters:
    hello.email.from: fabien@example.com
  • XML 
    <!-- app/config/config.xml -->
<parameters>
    <parameter key="hello.email.from">fabien@example.com</parameter>
</parameters>
  • PHP 
    // app/config/config.php
$container->setParameter('hello.email.from', 'fabien@example.com');
  • INI 
    [parameters]
hello.email.from = fabien@example.com

Получить параметры в коде можно из контейнера:

$container->getParameter('hello.email.from');

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

Семантическая конфигурация

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

  • Возможность определить больше чем просто параметры (например сервисы);
  • Лучшая иерархия в конфигурации (вы можете определять вложенные конфигурации);
  • “Умные” слияния (merging), когда несколько файлов конфигурации переопределяют существующую конфигурацию;
  • Валидация конфигурации (если вы определите XSD файл и используете XML);
  • Завершение при использовании XSD и XML (прим. пер: видимо тут имеется в виду автозавершение в IDE на основе XSD структуры XML)

Создание расширения (Extension)

Для того чтобы использовать семантическую конфигурацию, создайте расширение Dependency Injection, которое наследуется от Extension:

// HelloBundle/DependencyInjection/HelloExtension.php
use SymfonyComponentDependencyInjectionExtensionExtension;

class HelloExtension extends Extension
{
    public function configLoad($config, ContainerBuilder $container)
    {
        // ...
    }

    public function getXsdValidationBasePath()
    {
        return __DIR__.'/../Resources/config/';
    }

    public function getNamespace()
    {
        return 'http://www.example.com/symfony/schema/';
    }

    public function getAlias()
    {
        return 'hello';
    }
}

Класс, описанный выше определяет пространство имен hello:config, доступное в любом конфигурационном файле:

  • YAML 
    # app/config/config.yml
hello.config: ~
  • XML 
    <!-- app/config/config.xml -->
<?xml version="1.0" ?>

<container xmlns="http://www.symfony-project.org/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:hello="http://www.example.com/symfony/schema/"
    xsi:schemaLocation="http://www.example.com/symfony/schema/ http://www.example.com/symfony/schema/hello-1.0.xsd">

   <hello:config />
   ...

</container>
  • PHP 
    // app/config/config.php
$container->loadFromExtension('hello', 'config', array());
Замечание: вы можете создать столько методов xxxLoad(), сколько хотите определить конфигурационных блоков для вашего расширения.

Разбор конфигурации

Всякий раз, когда пользователь включает пространство имен hello.config в конфигурационный файл, вызывается метод configLoad() вашего расширения и конфигурация передается в виде массива (Symfony2 автоматически конвертирует XML и YAML в массивы).

Итак, мы имеем следующую конфигурацию:

  • YAML 
    # app/config/config.yml
hello.config:
    foo: foo
    bar: bar
  • XML 
    <!-- app/config/config.xml -->
<?xml version="1.0" ?>

<container xmlns="http://www.symfony-project.org/schema/dic/services"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:hello="http://www.example.com/symfony/schema/"
    xsi:schemaLocation="http://www.example.com/symfony/schema/ http://www.example.com/symfony/schema/hello-1.0.xsd">

    <hello:config foo="foo">
        <hello:bar>foo</hello:bar>
    </hello:config>

</container>
  • PHP 
    // app/config/config.php
$container->loadFromExtension('hello', 'config', array(
    'foo' => 'foo',
    'bar' => 'bar',
));

Массив, который будет передаваться в ваш метод будет таким:

array(
    'foo' => 'foo',
    'bar' => 'bar',
)

Внутри метода configLoad() переменная $container ссылается на контейнер, который знает лишь об этом пространстве имен. Вы можете манипулировать добавлением сервисов и параметров в нужном вам направлении. Когда метод вызывается первый раз, контейнер знает лишь о глобальных параметрах. При последующих вызовах он содержит конфигурацию, определенную предыдущими вызовами. Таким образом метод должен объединить новые настройки со старыми:

// only load default services and parameters once
if (!$container->hasDefinition('xxxxx')) {
    $loader = new XmlFileLoader($container, __DIR__.'/../Resources/config');
    $loader->load('hello.xml');
}

Глобальные параметры:

  • kernel.name
  • kernel.environment
  • kernel.debug
  • kernel.root_dir
  • kernel.cache_dir
  • kernel.logs_dir
  • kernel.bundle_dirs
  • kernel.bundles
  • kernel.charset
Предупреждение: все имена параметров и сервисов, начинающиеся с подчерка (_) зарезервированы для использования фреймворком и новые не должны определяться в пакетах.

Соглашения по созданию расширений

При создании расширения следуйте этим простым соглашениям:

  • Расширение должно находиться во вложенном пространстве имен DependencyInjection;
  • Расширение должно именоваться при помощи наименования пакета и завершаться суффиксом Extension (HelloExtension для HelloBundle) – если же вы создаете несколько расширений для одного пакета, просто завершайте их суффиксом Extension;
  • Алиас должен быть уникальным и должен именоваться также при помощи наименования пакета (hello для HelloBundle или sensio.social.blog для SensioSocialBlogBundle);
  • Расширение должно содержать XSD схему.

Если вы последуете этим рекомендациям, то ваше расширение автоматически будет зарегистрировано Symfony2. Если этого не произошло, переопределите метод пакета registerExtensions():

class HelloBundle extends Bundle
{
    public function registerExtensions(ContainerBuilder $container)
    {
        // register the extension(s) found in DependencyInjection/ directory
        parent::registerExtensions($container);

        // register extensions that do not follow the conventions manually
        $container->registerExtension(new ExtensionHello());
    }
}

Конфигурация по-умолчанию

Как определено ранее, пользователь пакета должен включить пространство имен hello.config в конфигурационный файл, для того чтобы вызывался код вашего расширения. Но вы также можете автоматически регистрировать конфигурацию по-умолчанию, переопределяя метод пакета registerExtensions():

class HelloBundle extends Bundle
{
    public function registerExtensions(ContainerBuilder $container)
    {
        // will register the HelloBundle extension(s) found in DependencyInjection/ directory
        parent::registerExtensions($container);

        // load some defaults
        $container->loadFromExtension('hello', 'config', array(/* your default config for the hello.config namespace */));
    }
}

Внимание: Symfony2 старается быть максимально открытым и понятным. Поэтому определение конфигурации по-умолчанию автоматически это наверняка не очень хорошая идея.

Оригинал тут: http://docs.symfony-reloaded.org/guides/bundles/configuration.html

Перевод как всегда – мой авторский ))

]]> http://hudson.su/2011/02/18/symfony-2-bundle-configuration/feed/ 6 ( PHP CLI & eAccelerator ) != love http://hudson.su/2011/02/16/php-cli-and-eaccelerator-ne-love/ http://hudson.su/2011/02/16/php-cli-and-eaccelerator-ne-love/#comments Wed, 16 Feb 2011 10:49:18 +0000 hudson http://hudson.su/?p=1774 На днях встал вопрос об оптимизации запуска cron-скриптов. Подавляющая часть – это таски symfony (т.е. выполняется что-то типа ./symfony namespace:taskname params) и даже в условиях использования nice они создают приличный оверхед на сервер.

В ходе разбора полетов решил уяснить, работает ли eAccelerator c php-cli. Собственно с подсказки @ibulatenko забрел на страницу http://eaccelerator.net/wiki/Faq, на которой черным по вебу написано в самом низу страницы:

Is eAccelerator working with php-cgi or php-cli?
This is not yet supported and it won’t be supported in the near future. However FastCGI is supported.

P.S. Судя по всему ни один акселератор не работает при использовании CLI интерфейса (по крайней мере точно известно про XCache, при этом там также написано что поскольку у CLI совершенно другой принцип работы, то и ожидать не стоит).

]]> http://hudson.su/2011/02/16/php-cli-and-eaccelerator-ne-love/feed/ 1 Symfony 2: пакеты, практические рекомендации http://hudson.su/2011/02/15/symfony-2-bundles-best-practices/ http://hudson.su/2011/02/15/symfony-2-bundles-best-practices/#comments Tue, 15 Feb 2011 07:58:29 +0000 hudson http://hudson.su/?p=1747 Пакет – прежде всего это директория, которая имеет строго определенную структуру и может содержать все что угодно (от классов, до контроллеров и web-ресурсов). Не смотря на то что пакеты очень гибки, вы должны следовать некоторым рекомендациям (best practices), если вы хотите выложить его в общий доступ. Об этих практиках мы и поговорим ниже:

Наименование пакета

Пакет – это, помимо всего прочего, также пространство имен. Пространство имен должно соответствовать стандартам совместимости PHP 5.3 для пространств имен и наименований классов: они должны начинаться с сегмента “поставщика” (вендора), содержать несколько сегментов категорий (в том числе может не содержать ни одного) и оканчиваться коротким наименованием пространства имен, которое должно, в свою очередь, завершаться суффиксом Bundle.

Пространство имен становится пакетом как только вы добавите в него класс пакета (bundle class). Наименование класса пакета должно соответствовать нескольким нехитрым правилам:

  • Использовать только буквы, цифры и подчерк;
  • Использовать ВерблюжийРегистр (aka CamelCase) для имени
  • Использовать описательные и короткие наименования (не менее 2х слов)
  • Использовать в качестве префикса наименование вендора (и опционально – категории пространства имен)
  • Использовать суффикс Bundle.

В таблице ниже приведены несколько примеров правильных пространств имен и наименований классов для пакетов:

Пространство имен Наименование класса
SensioBundleBlogBundle SensioBlogBundle
SensioBundleSocialBlogBundle SensioSocialBlogBundle
SensioBlogBundle SensioBlogBundle

По договоренности, метод getName() класса в пакете должен возвращать имя класса.

Структура директорий

Базовую структуру директорий пакета HelloBundle можно представить следующим образом:

XXX/...
    HelloBundle/
        HelloBundle.php
        Controller/
        Resources/
            meta/
                LICENSE
            config/
            doc/
                index.rst
            translations/
            views/
            public/
        Tests/

Структура директорий XXX отражает структуру пространства имен пакета.

Следующие файлы являются обязательными:

  • HelloBundle.php;
  • Resources/meta/LICENSE: текст лицензии на код пакета;
  • Resources/doc/index.rst: корневой файл документации пакета.

Замечание: следование этим соглашениям обеспечивает работу средств автоматизации.

Глубина под-директорий должна быть минимально необходимой для используемых классов и файлов (максимум 2 уровня). Больший уровень вложенности может быть использован для малозначимых или же редкоиспользуемых файлов.

Дирктория пакета предназначается только для чтения. Если вам необходимо писать временные файлы – вы можете сохранять их в директории cache/ или log/. Вы можете генерировать файлы в директории пакета при помощи различных инструментов, но только в том случае, если генерированные файлы будут частью репозитория.

Следующие классы и файлы имеют определенное расположение:

Тип Директория
Контроллеры Controller/
Файлы с переводами Resources/translations/
Шаблоны Resources/views/
Модульные и функциональные тесты Tests/
Web-ресурсы (доступные публично) Resources/public/
Конфигурация Resources/config/
Команды Command/

Классы

Структура директорий пакета используется как иерархия пространства имен Например, HelloController контроллер находится по пути Bundle/HelloBundle/Controller/HelloController.php и полное имя класса будет BundleHelloBundleControllerHelloController.

Все классы и файлы должны соответствовать стандартам кодирования Symfony2.

Некоторые классы следует рассматривать как фасады (facades) и стараться делать их как можно более короткими, например Commands, Helpers, Listeners и Controllers.

Классы, которые подключаются к Event dispatcher’у должны иметь суффикс Listener.

Классы исключений должны быть расположены во сложенном пространстве имен Exception.

Вендоры

Пакет не должен включать сторонних PHP-библиотек. Вместо этого они должны располагаться в стандартной директории Symfony2, доступной автозагрузчику. Также пакет не должен включать сторонних библиотек на JavaScript, CSS или на других языках.

Тесты

Пакеты должны комплектоваться набором тестов на PHPUnit и расположенными в директории Tests/. Тесты должны следовать следующим принципам:

  • Тестовый набор должен выполняться простой командой phpunit из демо-приложения;
  • Функциональные тесты должны быть использованы только для тестирования ответов (response output) и профильных данных, если таковые имеются;
  • Покрытие кода должно составлять не менее 95% кода вашего пакета.

Замечание: тестовый набор не должен содержать скрипта AllTests.php, но должен полагаться на наличие файла phpunit.xml.dist.

Документация

Все классы и функции должны быть документированы в стиле PHPDoc.

Полная документация также должна быть представлена в формате reStructuredText, и располагаться в директории Resources/doc/; наличие файла Resources/doc/index.rst – обязательно!

Контроллеры

Контроллеры в пакете не должны наследоваться от класса Controller. Они должны реализовывать интерфейс ContainerAwareInterface или наследоваться от класса ContainerAware.

Замечание: Если вы посмотрите на методы класса Controller, вы заметите что они представляют собой “ярлычки” для упрощения изучения.

Шаблоны

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

Файлы переводов

Если пакет содержит переводы сообщений, они должны быть определены в формате XLIFF;

If a bundle provides message translations, they must be defined in the XLIFF format; домен должен располагаться после имени пакета (bundle.hello).

Пакет не должен переопределять уже существующие сообщения из других пакетов.

Конфигурация

Конфигурация пакета должна использовать строенный механизм Symfony2. Пакет должен предоставлять все его базовые настройки в виде XML.

Оригинал тут http://docs.symfony-reloaded.org/guides/bundles/best_practices.html

Перевод как обычно авторский )

]]> http://hudson.su/2011/02/15/symfony-2-bundles-best-practices/feed/ 2 Symfony 2 для разработчиков на symfony 1.x http://hudson.su/2011/02/12/symfony2-for-symfony1-developers/ http://hudson.su/2011/02/12/symfony2-for-symfony1-developers/#comments Sat, 12 Feb 2011 12:51:32 +0000 hudson http://hudson.su/?p=1718 Symfony 2.0 по сравнению с первой версией фреймворка шагнул далеко вперед. К счастью, MVC архитектура, лежащая в основе его ядра, позволяет использовать те же навыки, что вы использовали, разрабатывая приложения для symfony1 и для Symfony2. App.yml вы конечно тут не увидите, но маршрутизация, контроллеры и шаблоны сохранились.

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

Итак, расслабьтесь, и внимайте.

Структура директорий

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

Директория app/

В symfony1 ваш проект мог иметь одно или больше приложений, каждое из которых располагалось в директории apps/ (например apps/frontend). По умолчанию в Symfony2 у вас есть лишь одно приложение, которое расположено в директории app/. Как и в symfony1 директория app/ содержит конфигурационные файлы приложения. Также тут содержится кеш приложения, лог и директории для шаблонов, а так же класс Kernel (AppKernel), который является базовым объектом, представляющим приложение.

В отличие от symfony1 в директории app/ в основном располагается не PHP-код. Эта директория не содержит модулей или библиотек, как это делает symfony1. Вместо этого, тут расположены конфигурационные файлы и прочие ресурсы (шаблоны, файлы переводов и т.п.).

Директория src/

Будем кратки: основной ваш код располагается здесь. В Symfony2 весь код приложения располагается в пакете (bundle, который приблизительно можно сравнить с плагином в symfony1) и, по умолчанию, каждый пакет располагается в директории src/. Таким образом, директорию src можно сравнить с директорией plugins в symfony1, но все-таки она дает разработчику больше свободы и гибкости. Также, в случае, если ваши пакеты располагаются в директории src/, сторонние пакеты можно расположить в директории vendor/.

Для того чтобы получить более полную картину о директории src/, давайте вспомним о том как у нас все было организовано в приложении symfony1. Часть вашего кода скорее всего располагалась в одном или более приложений. Как правило код включал в себя модули, но это также могли быть прочие классы, которые вы сочли нужным разместить там. Вы также могли создать файл schema.yml в директории config вашего проекта и создать множество файлов модели. Наконец, для того чтобы не изобретать велосипеды, вы пользовались несколькими сторонними плагинами, которые располагались в директории plugins/. Другими словами, код, заставляющий взлетать ваше приложение, располагался в множестве различных мест.

В Symfony2 жизнь намного проще, потому что весь код приложения в Symfony2 должен располагаться внутри пакета (bundle). Следуя аналогии, в symfony1 весь наш код должен был бы быть размещен в одном или нескольких плагинах (что само по себе является неплохой практикой). Полагая что все наши модули, PHP классы, схема, конфигурация маршрутизатора и т.д. переедут в плагин, тогда директория plugins/ из symfony1 будет очень похожа на директорию src/ в Symfony2

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

Директория vendor/

Директория vendor/ в основном похожа на директорию lib/vendor из symfony1, которая была общепринятым местом хранения всех сторонних библиотек. По умолчанию, вы найдете в этой директории библиотечные файлы Symfony2, а также несколько вспомогательных библиотек, таких как Doctrine2, Twig и Swiftmailer.

Директория web/

В директории web/ поменялось не так уж и много. Наиболее заметное изменение – это отсутствие директорий css/, js/ и images/. Не беспокойтесь, это было сделано преднамеренно. Как и в случае с вашим PHP кодом, все ассеты также должны располагаться внутри пакета (bundle). При помощи консольной команды, директория Resources/public каждого пакета копируется или линкуется символической ссылкой в директорию web/bundles/. Это позволяет вам упорядоченно хранить ваши ассеты внутри пакета, а также делать их доступными пользователям. Для того чтобы быть уверенными, что все пакеты доступны, выполните следующую команду:

./app/console_dev assets:install web --symlink
Отметим также, что эта команда эквивалентна команде symfony1 - plugin:publish-assets.

Автозагрузка

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

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

В Symfony2 за этот процесс отвечает класс UniversalClassLoader. Идея его проста: имя класса (включая пространство имен) должно соответствовать пути к файлу, который содержит класс. Давайте рассмотрим HelloController из песочницы Symfony2 в качестве примера:

namespace SensioHelloBundleController;
use SymfonyBundleFrameworkBundleControllerController;
class HelloController extends Controller
{
    // ...

Сам файл располагается по пути src/Sensio/HelloBundle/Controller/HelloController.php. Как вы видите, расположение файла соответствует пространству имен класса. А именно, пространство имен SensioHelloBundleController, сообщает что директория, где будет расположен файл – srcSensioHelloBundleController.

Если файл не будет найден по ожидаемому пути, вы получите ошибку: Class "SensioHelloBundleControllerHelloController" does not exist.. В Symfony2 ошибка “class does not exist” означает, что пространство имен класса и его физическое расположение на диске не совпадают. Таким образом, Symfony2 ищет класс в одном единственном месте, которое ему положено. Кроме того, для того чтобы класс был автозагружен, вам никогда не придется очищать кеш в Symfony2.

Тем не менее, для того чтобы автозагрузчик работал правильно, ему нужно знать, что пространство имен Sensio расположено в директории src и, например, что пространство имен Doctrine располагается в директории vendor/doctrine/lib/. Данные правила полностью контролируются разработчиком (вами) посредством файла app/autoload.php.

Консоль

В symfony1 консоль располагалась в корневой директории вашего проекта и называлась symfony.

В Symfony2 консоль располагается в суб-директории приложения и называется console.

Консоль обслуживает только одно окружение (например dev, prod). Это поведение отличается от symfony1, где некоторые задачи (task) позволяли вам указать окружение через опцию env=. Распространённой практикой является создание отдельного командного файла для каждого окружения. Как правило это означает наличие файла console для prod и console_dev для dev окружений.

Приложения

В проекте на symfony1 обычной практикой было создавать несколько приложений: например frontend и backend.

В проекте на Symfony2 вам нужно создать лишь одно приложение (блог, интранет-портал…). В большинстве случаев, если вы захотите создать еще одно приложение, вы можете вместо этого создать еще один проект и обеспечить доступность необходимых пакетов между ними.

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

Конечно же, наличие нескольких приложений в проекте не будет совершенно неправильным шагом, но это целиком ваш выбор. Второе приложение будет означать новую директорию, например my_app/, с настройками, аналогичными тем, которые находятся в директории app/.

Совет: почитайте определения проекта, приложения, и пакета в глоссарии.

Пакеты и плагины

В проекте symfony1 плагин должен содержать конфигурацию, модули, PHP библиотеки, ассеты и все прочее, относящееся к вашему проекту. В Symfony2 место плагина заняли пакеты (bundles). Пакет даже более функционален нежели плагин, потому что ядро Symfony2 состоит из последовательности пакетов. В Symfony2 пакет это гражданин высшего сорта, настолько гибкий, что даже ядро это пакет.

В symfony1 плагин должен быть активирован в классе ProjectConfiguration:

// config/ProjectConfiguration.class.php
public function setup()
{
    $this->enableAllPluginsExcept(array(/* some plugins here */));
}

В Symfony2 пакеты активируются внутри ядра приложения:

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        new SymfonyBundleFrameworkBundleFrameworkBundle(),
        new SymfonyBundleTwigBundleTwigBundle(),
        // ...
        new SensioHelloBundleHelloBundle(),
    );

    return $bundles;
}

Также необходимо удостовериться что пространство имен Sensio присутствует в автозагрузчике:

// app/autoload.php
$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
    'Symfony'                        => __DIR__.'/../vendor/symfony/src',
    'Sensio'                         => __DIR__.'/../src',
    // ...
));

В symfony1 конфигурационные файлы routing.yml и app.yml загружались автоматически для любого плагина. В Symfony2 маршруты и конфигурация приложения из пакета должны быть подключены вручную. Например, чтобы подключить маршрутизацию из пакеты, вы должны выполнить следующее:

# app/config/routing.yml
hello:
    resource: @HelloBundle/Resources/config/routing.yml

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

Оригинал тут: http://docs.symfony-reloaded.org/guides/symfony1.html

Перевод авторский ;)

]]> http://hudson.su/2011/02/12/symfony2-for-symfony1-developers/feed/ 20 Symfony без слэша на хвосте http://hudson.su/2010/06/12/symfony-without-trailing-slash/ http://hudson.su/2010/06/12/symfony-without-trailing-slash/#comments Fri, 11 Jun 2010 20:09:43 +0000 hudson http://hudson.su/?p=1558 Часто-часто задаваемый вопрос в канале по symfony:

  • как избавиться от слэша на конце URL
  • почему DoctrineRouteCollection не принимает последний слэш
  • и т.д. в том же духе

Так вот вам просто сниппет в помощь:

#to avoid trailing slash problem
RewriteRule ^(.+)/$ http://%{HTTP_HOST}/$1 [R=301,L]

Научной ценности сниппет не представляет, но вопрос действительно часто спрашиваемый ) Так что “ищите и обрящете” ))

Have fun!

]]> http://hudson.su/2010/06/12/symfony-without-trailing-slash/feed/ 1 BitNami – помощник ленивому программисту http://hudson.su/2010/05/30/bitnami-helps-lazy-programmer/ http://hudson.su/2010/05/30/bitnami-helps-lazy-programmer/#comments Sun, 30 May 2010 06:42:38 +0000 hudson http://hudson.su/?p=1520

Кросспост из моего хабра.

Век живи – век учись.

Ковыряясь в публикациях о Ruby на википедии наткнулся на замечательный проект, который не только поможет ленивому программисту поднять development среду для своих нужд, но также во многих случаях выручит и администратора и менеджера проектов. Проект этот называется BitNami.

Что же такое – BitNami?

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

BitNami Stack представляет собой интегрированный пакет программного обеспечения, которое включает в себя веб-приложение и все его необходимые компоненты (веб-сервер, базу данных, Language Runtime), поэтому он готов к запуску “из коробки”. Stack’и могут быть представлены в виде нативных инсталляторов, образов виртуальных машин,  или образов для облачного хостинга.

Нативные инсталляторы – это отдельные исполнимые файлы, которые вы можете загрузить к себе на машину. После запуска инсталлятора будет выполнен пошаговый атоматический процесс установки выбранной системы. Инсталляторы доступны для Windows, Mac OS X, Linux и Solaris (согласитесь, этого более чем достаточно в 95% случаев).

Образы виртуальных машин – это преднастроенные виртуальные машины, которые включают минимальную инсталляцию Linux и собственно компоненты BitNami Stack. Образы виртуальных машин доступны для VMWare и последних версий VirtualBox.

Образы для облачного хостинга позволяют вам запустить BitNami Stack в облачном окружении и программно запускать или останавливать его. Облачные образы на текущий момент доступны для Amazon EC2, кроме того планируется также поддержка других облачных хостингов.

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

На текущий момент доступно уже несколько десятков стеков. Вот некоторые из них:

  • Infrastructure
    • DjangoStack
    • LAMPStack
    • RubyStack
    • …
  • Blog
    • WordPress
    • …
  • Bug-Tracking
    • Redmine
    • …
  • CMS
    • Drupal
    • Joomla
    • Radiant CMS
    • …
  • Forum
    • phpBB
  • Version Control
    • Subversion
  • Wiki
    • DokuWiki
    • MediaWiki
    • …

Где же могут нам пригодиться BitNami Stacks?

  • Локальные девелоперские среды.
  • Вируализация девелоперских сред на централизованных началах (безобразно, но однообразно, как в армии).
  • Тестирование CMS, Wiki, багтрекеров – поиграться, чтобы понять, а нужно ли оно вообще, подходит ли.
  • Развертывание быстрых конфигураций в продуктовых средах (облачный хостинг как минимум).
  • Ваш вариант?

Я уже опробовал VMWare образы Python/Ruby/Redmine – очень понравилось. Django Stack (native installer) почему-то не установился на Win7 – что-то с PostgreSQL, пока детально не разбирался.

Вот вкратце и все. Надеюсь, был полезен ))

]]> http://hudson.su/2010/05/30/bitnami-helps-lazy-programmer/feed/ 0 Конференция Symfony Camp UA 2010 http://hudson.su/2010/05/28/symfony-camp-ua-2010/ http://hudson.su/2010/05/28/symfony-camp-ua-2010/#comments Fri, 28 May 2010 06:16:15 +0000 hudson http://hudson.su/?p=1512 Конференция Symfony Camp UA 2010

Приглашаем всех желающих посетить конференцию по Symfony PHP Framework, которая состоится 3 июля 2010 года в г.Киев. Участие в конференции – бесплатное. Зарегистрироваться на мероприятие.

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

Планируемые доклады

Перевод боевого сайта с ветки 1.0 на ветку 1.4

Руслан Ханов (Россия, Новосибирск)

Как мы делали langwhich.com и unique-shopper.com?

Денис Пищенко, Дмитрий Одуло (Украина, Харьков)

Symfony как платформа для open-source проектов (Sympal, Apostrophe, Diem)

Александр Демченко (Украина, Харьков)

Многоязычные сайты на Symfony. Проблемы и их решения

Игорь Бровченко (Украина, Киев)

Сontinuous Integration для Symfony

Игорь Бровченко (Украина, Киев)

LESS, SASS, HAML: 4 буквы, изменившие frontend development

Константин Кудряшов (Белоруссия, Минск)

Symfony Task – задачи батча (пакетной обработки). Как использовать, как улучшить

Александр Безрученко (Россия, Таганрог)

Кастомизация генераторов в Symfony 1.3/1.4. Эффективное управление функционалом и структурой плагинов

Николай Зык (Украина, Киев)

Философия сервисов. Практическое применение в Symfony 1.3/1.4

Николай Зык (Украина, Киев)

Symfony 2 – перезагрузка?

Александр Демченко (Украина, Харьков)

Этапы разработки реального проекта на Symfony 2 + Doctrine 2

Александр Скорней (Украина, Киев)

Внедрение компонента templating в существующий проект

Станислав Сметанин (Россия, Ижевск)

Подробности и новости:

Сайт конференции:

symfonycamp.org.ua

Twitter:

@SymfonyCampUa

Если Вы находите возможным поддержать конференцию, можете связаться с организаторами .

]]> http://hudson.su/2010/05/28/symfony-camp-ua-2010/feed/ 0