Время создавать новый виртуальный хост Apache, и я в порядке; Я скачал последнюю версию кандидата Symfony 2 в виде стандартного пакета со связанными зависимостями. Я копирую содержимое в папку Symfony / в корне моего документа: они весят около 15 МБ. Я — пользователь Zend Framework, и ZF выросла почти до 100 МБ — 15 МБ не проблема, место дешево.
При установке Symfony 2 я загружаю URL-адрес конфигурации, который проверит мои странные настройки php.ini; Мне не хватало конфигурации часового пояса на этой машине для разработки, поскольку я в основном использую командную строку, а не PHP через Apache.
Состав
Настройка в браузере напоминает мне немного CMS старого стиля, как Joomla и Drupal (ересь!), Но на самом деле собирается упростить жизнь конечных пользователей. Symfony 2 также поставляется с предварительно сгенерированной структурой папок:
- Приложение : настройка маршрутов, безопасность, кеш … К счастью, все это уже есть. Нет ничего более расстраивающего, чем начинать писать код и узнавать, что необходимо создать какой-нибудь файл конфигурации в эзотерическом формате и на языке разметки.
- src : код ваших пакетов, обычно контроллеров, а также всего, что они используют.
- vendor : библиотеки, такие как Doctrine и Twig, а также те, которые вы добавите. Все в комплекте (невероятно слабый каламбур), и сборка этих библиотек с нуля была бы большой работой.
- web : статические файлы и фронт-контроллеры, что, как я полагаю, означает, что это единственный каталог, который может быть представлен в качестве корня документа. Однако я вижу множество файлов .htaccess, которые не позволяют HTTP-клиентам спускаться в личные папки, такие как src /.
Я снова могу сравнить эту структуру с Zend Framework (1.x), другим крупным игроком в сфере PHP. Обычно эта структура генерируется Zend_Tool, вызываемым через командную строку, и существует дополнительный шаг, где необходимо установить zf . Опыт Symfony пропускает этот проблемный шаг.
Стек MVC
Стек Model-View-Controller является одной из основных причин принятия PHP-фреймворка: в противном случае вы просто используете библиотеку.
Контроллеры очень похожи на Zend Framework: это классы со списком действий, которые принимают объект запроса и выдают ответ. Тот же паттерн Action Controller все еще с нами.
Использование метода рендеринга также является аналогом:
return $this->render('AcmeDemoBundle:Welcome:index.html.twig');
render () возвращает ответ, который, в свою очередь, всегда должен возвращаться действием: это четкий контракт. Есть также Api для доступа к объекту запроса и сеансу, а также встроенный помощник по флеш-сообщениям .
Кстати, я обнаружил, что аннотация @Template () может быть вставлена для автоматической визуализации шаблона вместо явного вызова render (). В этом случае действие просто возвращает массив данных представления вместо объекта ответа.
Шаблоны написаны на Twig, но это только по умолчанию: не навязывание вам. Точно так же Yaml является только настройкой по умолчанию, и вы можете выбрать простой код PHP.
Маршрутизация кажется немного более сложной, чем остальная часть стека MVC, но я думаю, что мне нужно просто углубиться в нее:
- контроллер, используемый для определенного шаблона или префикса, настраивается через ClassNameController :: methodName или сокращением его до Namespace: BaseClassName: Action.
- в общем, ресурсы, определенные с логическими именами, сокращены соглашением вместо полного пути. Это немного косвенное обращение к физическим файлам, которые могут пригодиться
@AcmeDemoBundle/Controller/DemoController.php
означает
Acme/DemoBundle/Controller/DemoController.php
Маршруты также могут быть определены как аннотации на методах контроллера: все это использование аннотаций напоминает мне Doctrine 2, которая действительно включена в качестве ORM по умолчанию.
Что мне нравится (и я ZFer)
Прежде всего, код, как поставщика, так и приложения, организован в пакеты: я рад, что теперь существует формальная единица, определенная для папок или пространств имен.
Во-вторых , консоль командной строки просто работает из любой папки:
php app/console
Такое поведение нелегко понять с помощью установки tarball, но Symfony делает это правильно.
В-третьих , к производительности относятся серьезно: все из конфигурации кэшируется, и на это указывают. установка APC также является предложением в начальной конфигурации, где вы смотрите на php.ini.
В любом случае, сборка окончательного пакета действительно важна для простоты использования и опыта разработчика: за разработчиком следуют на каждом этапе настройки, и первое, что ему нужно сделать, это сложность, а не случайность: написание новый контроллер действий.
ZF 2 понадобится нечто подобное, если он хочет остаться вместе с Symfony, учитывая лучшее время выхода на рынок последних: упрощение исключений и переход к пространствам имен являются хорошими шагами, но на самом деле не новаторскими.