Как изменить тип конфигурации в бандле symfony 2?

Question

[nepster-web]

Продолжаю общаться с symfony 2 и мне понравилась такая штука как аннотации. Возник вопрос, а можно ли изменить в уже существующем бандле тип конфигурации на аннотации ?

Сейчас я знакомлюсь и работаю только с тестовыми бандлами (их без проблем можно пересоздать), однако если в будущем все-же нужно будет изменить конфигурацию на аннотации, можно ли это сделать скажем какой-то консольной командой (так как поправить файл одного конфига недостаточно)?

Answer 1

[Сергей Протько]

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

Я лично предпочитаю аннотации использовать только для маршрутизации в контроллерах и для каких-то вещей которые я хочу конфигурить (десериализация запроса из json в энтити например). Все остальное в yml выношу.

Comments

[nepster-web]

Тут проблема, если при создании бандла указать yml, то симфони начинает ругать вот такую штуку
/**
* @Route("/create")
*/

Тоесть она просто не работает.

[Sergej]

Я все выношу в yml'ы. Как то привык.
Под каждый бандл свои yml.

[nepster-web]

@sayber: а можно все в yml, а роуты в аннотации ?

[Alex]

@nepster09: всё, что генерирует симфони, можно будет поменять.

Что касается Route, то либо use не прописали, либо в app/config/routing.yml не указали путь к папке с контроллерами, и Symfony просто не знает, что там надо искать эти аннотации.

xxx:
    resource: "@ZzzBundle/Controller"
    type: annotation

[Sergej]

@nepster09: Вы загляниnе в документацию. Даже по умолчанию консоль все генерирует в yml.

Простой пример роута бандла и контроллера.

step.one.action:
   pattern:  /step/one/
   defaults: { _controller: FrontCopyrightedBundle:Default:step }
fields.action:
   pattern:  /fields/
   defaults: { _controller: FrontCopyrightedBundle:Default:getFields }<
/code>

[Sergej]

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

[nepster-web]

@sayber: хочу аннотации.

@shoomyst таки да, use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route

[Sergej]

@nepster09: Ваше право.

[nepster-web]

@sayber: в смысле аннотации для роута =). Кстате я раньше работал с Yii2, по сравнению с симфони пока счет 1 1 (аннотации тащят).

[Сергей Протько]

@nepster09: вам еще предстоит открыть целый новым мир, раз 1:1 у вас...

[BoShurik]

@nepster09: интересно, как Yii заработал свое очко?

[nepster-web]

@BoShurik: я вначале читал кучу доков по симфони, только вот сейчас приступил к установке и созданию бандлов. Мне не очень понравилась идея с геттерами и сеттерами в симфони, тоесть в yii это проще реализовали через магические методы. В симфони у меня вышла сущность из 150 строк кода, которая по сути ничего не делает, одни сплошные геттеры и сеттеры. Хотя бонус в том, что все изолированно и нет никаких зависимостей, но все-же тут очко в пользу Yii.

Конфигурации в симфони yml и xml, ну за это я бы снял очко, так как yml это обычный файл, от которых еще в 90 ушли, xml умер (скоро совсем умрет) после появления json. Еще я думал даль очко yii за роутинг, но аннотации втащили. тоесть это вообще крутая штука и тут очко симфони по любому.

Дальше я еще не совсем пощупал доктрину, тоесть пока актив рекорд мне нравится больше.

Дальше, то что нужно самому выгружать ацесты, ну это напряжно, хотя я их еще не копал поэтому не знаю что как.

Понравилась структура симфони, тоесть меньше мусора будет, можно будет получить пару новых скиллов в проектировании.

Не понял момента с Запрос - Ответ, что контроллер должен постоянно возвращать объект Responce, ну тоесть все логично, нормально и при этом в yii это сделано как-то неявно, тоесть на быструю руку для теста echo 'Hello' будет работать.

Взбесило, то что вместо привычного actionIndex в симфони indexAction.

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

Интересный модход к миграциям в симфони, вроде не плохо.

Еще не работал, но смотрел на формы и мне кажется за валидацию и организацию форм в симфони я бы снял баллов 20. Хотя возможно я не понял как они работают, но в yii2 с этим на много проще и удобнее.

Смутило отсутствие понятия виджет. Тоже про модели, добавились новые паттерны (о которых я не знал). Хотя у меня всегда душа лежала к примерно таким штукам, изолированным (yii мне их предоставить почти всегда отказывался).

1 1, так как это то что я действительно протестировал и там и там, сравнил и понял.
Меня вот так просто взяли и пересадили на симфони, поэтому я не особо доволен и прежде чем писать что-то, я внимательно изучаю чо как тут работает.

Пока я могу сказать точно:
- Yii2 + за простую организацию моделей (геттеров и сеттеров)
- Симфони + за аннотации, очень удобная штука особенно для роутинга и для создания полей в базе
еще пожалуй:
- Yii2 + за простую удобную конфигурацию предложенную через массивами или в базе данных. Я считаю, что yml должен был умереть в 90 и 2000 как и cms на файлах. Xml ну да это круто все дела, было до того как родился Json. В общем конфигурация в Yii2 пока удобнее.

[Alex]

@nepster09: есть большая вероятность, что вы просто не готовы к Symfony. Это нормально: нельзя после проектирования мебели переключиться на проектирование ракет. Каждый разработчик проходит определенные этапы развития, вы сейчас на этапе yii/laravel :) Главное чтобы было желание развиваться дальше

[Сергей Протько]

@nepster09: То о чем вы говорите это не Yii vs Symfony а ActiveRecord vs DataMapper или если хотите RAD vs ООП. Видели шутку про три самых важных слова? Инкапсуляция, наследование и полиморфизм. Так вот, публичные поля, которые доступны на запись откуда угодно, это нарушение инкапсуляции. В php7 хотят вот ввести readonly модификатор доступа и эта проблема для Yii будет решена. Да и вам никто не мешает сделать для ваших сущностей базовый класс с __get/__set атрибутами которые имеют доступ к protected полям. Хотя я опять же не рекомендую так делать так как возникнут проблемы с формами и вообще.

На самом деле это вообще не проблема а только плюс. Вы проектируете не базу данных а классы, сущности которыми будет оперировать бизнес логика вашего приложения. Есть такая штука, DDD называется. Domain Driven Design (не development). То есть мы начинаем проектировать систему не с сервисов/контроллеров/баз данных, а именно с наших доменных моделей. Формируем связи между ними, суровые дядьки делают это при помощи UML и т.д. Причем то как данных хранятся можно решить потом, когда выстроится структура приложения и описать в мэппинге. А в сеттерах/геттерах проводить какую-то минимальную валидацию и конвертацию данных. Делать параметризованные сеттеры, делать нормальные конструкторы (например класс Post принимает в конструктор объект типа User и не дает нам создать пост не указав автора).

Это позволяет добиться того, что мы уменьшаем количество потенциальных ошибок а так же если проект реально серьезный, мы можем обеспечить ему статический анализ (если это можно так назвать, все же без статического тайпхинтинга сложно это сделать) и в автоматическом режиме искать места потенциальных ошибок (например инстанцирования того же Post без передачи ему пользователя, или неверный порядок аргументов или что-то в этом духе).

Если же вы не паритесь, нормальная IDE умеет генерить геттеры и сеттеры для полей класса. Я жалею немного что в 2012-ом не приняли RFC сокращенного синтаксиса геттеров/сеттеров... тогда было бы как в c# или js... и код был бы няшнее... и readonly не нужны были... но видимо на то были причины, я если честно не разбирался почему отказались.

Если active record вам нравится больше, можете посмотреть в сторону Propel-а или переключиться на Laravel - на нем можно писать такой же качественный код как на symfony (с оговорками конечно)... правда если учиться по их документации и статьям по этому фреймворку шансов на это малова-то...

Что до xml vs json - ой как вы не правы. json тупой формат. xml - универсальный. XML имеет одно огромное преимущество перед json - атрибуты. У JSON у вас на вооружении только массивы и объекты. Если вы в поле объекта храните строку, а в один прекрасный день строка заменилась на массив строк, то клиент парсящий этот json и обрабатывающий данные сломается, так как он все еще ожидает увидеть строку. С XML у нас был один элемент со строкой - а стало несколько. XPath выберет первый элемент как выбирал до этого и все будет хорошо. Это решает огромную проблему с версионизацией API сервисов... но всем пофиг, json же проще парсить. Так же за счет отсутствия атрибутов в JSON люди придумывают кучу кастылей для реализации штук типа hateous и т.д. Короче... зачем использовать XML? Во славу REST конечно! Проблему версионизации конфигов оно так же решает...

В любом случае json и xml это форматы для машин, yaml - для людей. Опять же в IDE для них есть автокомплит в контексте конфигов Symfony2. Ну и опять же - просто вам нужно привыкнуть.

assetic меня тоже напрягает... потому не использую его, собираю все gulp-ом. Как в прочем и на yii когда-то grunt-ом собирал асеты ибо терпеть не мог этот ущербный AssetManager.

Что до того что контроллер всегда должен возвращать ответ - это логично. Как работает клиент-сервертая архитектура? Клиент отправляет запрос на сервер и хочет получить ответ. Объект Response инкапсулирует в себе HTTP ответ а Request - HTTP запрос. Что это нам дает? Мы обстрагируемся от SAPI которое использует разработчик. Все унифицировано и т.д. Более того, если вы используете php-fpm, то Symfony после того как получит объект Response отдаст его и скажет php-fpm-у что ответ отправлен, больше ничего не жди. И php-fpm отправит это в вэб сервер а тот клиенту, то есть запрос завершен. НО PHP все еще продожлает работать, например отправлять почту, генерить превьюшки для постов и т.д. То есть все тежелые операции которые не влияют на ответ можно отложить на событие kernel.terminate. Собственно swiftmailer почту там отправляет и время отправки почты не влияет на время запроса с клиента.

Так же есть такая вещь как middlewares. То есть мы можем делать слоеный пирог из приложения. Один слой берет запрос, добавляет к нему что-то или забирает и передает другому слою. Скажем мы можем выделить в отедльный слой все что связано с проверкой прав доступа и авторизации (в symfony оно так и работает но в рамках одного слоя и на ивентах). То есть контроллеру вообще об этом париться не нужно. Ну или типичный пример для API - добавить поддержку CORS можно просто подключив одной строчкой middleware (ну или поставить бандл... не суть).

В Yii же у вас была абстракция над запросом... и то она просто брала данные из SAPI PHP и верило ему наслово. Никакого изыска. Так как все выводится простым echo перехватить и обрабоать запрос можно было только кастылями и тд. Короче ад... особенно в плохих руках.

По поводу именования actionIndex и indexAction - открою вам маааленький секрет. Это имеет какое-то значение только если вы конфиги маршрутизации в yaml храните для этих экшенов. А так называйте метод как хотите, правило маршрутизации за ним всерано закрепится. Так что называйте хоть так хоть эдак хоть megaSuperIndexAction.

Что до шаблонизаторов - я в одном из вопросов описывал, можете почитать. Вообще если вы научитесь пользоваться Twig-ом писать на plain-php шаблоны вам больше никогда не захочется. Наследование, фильры, автоэскейпинг... ух... И вы не представляете какой я испытал восторг в свое время когда смог всего за пару часов разобраться как расширять парсер своим синтаксисом, блоки свои делать, какую-то свою хитрую логику сборки и компиляции шаблонов... И да, зная twig вы автоматом сможете выучить шаблонизатор jinja для python в случае если вам когда-нибудь придется столкнуться с ansible.

Опять же миграции - это фича доктрины и только ее. Для меня это жирнющий плюс, то что я могу добавить сущность или поле у сущности, сделать migration:diff и просто слегонца поправить миграцию... и все будет хорошо... и у всех все будет хорошо. Я если честно начинаю подзабывать SQL-ые ALTER TABLE с такими делами...

В Yii все проще с формами и валидацией... потому что форм там нет... а валидация совмещена с сущностями. Я помню меня немного напрягало что в Yii1 почти никто не использовал форм билдер, хоть он там и был. А потом я поработал с Symfony Forms и понял почему никто им не пользовался - он ущербный и бесполезный в большинстве случаев. А на Symfony Forms вы можете реализовать вообще любую форму, покрыть это дело тестами и не вставлять кастылей. Правда этот компонент пожалуй самый сложный и может порвать ваш мозг пока вы вьедите во всю прелесть оного... Для простеньких форм в принципе ничего страшного там нет. В случае с валидацией все довольно просто - не вижу смысла останавливаться на ней. Просто это логично что за валидацию должен отвечать отдельный компонент. Более того, он очень гибок за счет того что он отдельный. Короче все проблемы именно изза того что вы не разобрались пока. Валидацию думаю вы быстро освоите, а от форм будете плеваться пока не постигните дзен.

Виджет это просто название. У вас есть HMVC, который намного более гибкий. А добавьте к этому наследование шаблонов и блоки и проблем с масштабированием шаблонов вообще не будет. В YIi при помощи виджетов решали проблему дублирования кода при формировании страницы. В Symfony нашли более качественное решение.

Я сам когда-то в 2011-ом был вынужден пересесть на Symfony2, первый месяц мне было некомфортно после Yii1 который я знал вдоль и поперек, излазил все исходники и досканально знал как работает большая часть его компонентов. И тут на тебе... новый фреймворк (ну как новый... я как-то тыкал Symfony1 так что что-то уже понимал но на тот момент не понимал полностью) и все сложное и нужно много думать... Но вот прошли три года и я низачто не хочу переходить на какой либо другой фреймворк. Еще на Laravel могу посмотреть, на Zend... а так если уж не SYmfony то пойду колупать RoR или Django, который я забросил лет 6 назад.

Короче подытожим. Yii это хорошо для того что бы клепать сайтики. ПРоблема в Yii в том что если у разработчика это один из первых фреймворков и еще не сложилось какое-то понятие о культуре разработки, то он будет писать говнокод и будет крайне медленно из этого дела выплывать (все зависит от характера конечно).

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

[Sergej]

@Fesor: фига вы тут развели, вам пора в отдельный хаб =)

[Sergej]

Золотые слова.

Вообще если вы научитесь пользоваться Twig-ом писать на plain-php шаблоны вам больше никогда не захочется.

[nepster-web]

@Fesor: спасибо большое за комментарии, да вот буду колупать the симфони, чтобы на одного говнокодера было меньше и вы не плевались если вдруг когда-то нужно будет после меня допиливать проект =)