Но ведь вам никто не мешает разносить роутинг по бандлам! Более того, это даже рекомендуемый путь для Symfony2-приложений. При генерации бандла конфигурация роутинга для него не конкатится к app/config/routing.yml, а инклудится в нем:
И что еще важнее, вы вполне можете объявить несколько конфигураций роутинга в рамках одного бандла, либо точно так же инклудить другие конфиги при помощи resource.
Получается, что в пути src/My/AcmeBundle/resources/config могут быть, например, сразу routing_front.yml и routing_admin.yml, импортируемые в app/config/routing:
Ну, это про поиск и навигацию по аннотированным @Route экшенам. А если вы вдруг, например, захотите во всех экшенах суффикс _list заменить на _index, например? Или, например, для всех рутов с суффиксом _new ограничить методы только POST'ом?
Имхо, куда удобнее будет сделать изменения в одном или нескольких routing.yml и получить красивый и аккуратный коммит, по changeset'у которого явно видно, что он касается только роутинга, нежели получить изменения в большинстве, а то и во всех контроллерах.
Кстати, это еще один аргумент за конфиги и против аннотаций.
Ну, согласитесь, что в учебных целях вполне можно и про PHP-шаблоны рассказать, а уже потом пояснить, почему оно плохо, и почему нужно учить еще и Jinja-синтаксис из Твига.
Ну, вы вполне можете реализовать контроллер-адаптер более абстрактно, чтобы минимизировать его зависимость от тех контроллеров, которые он оборачивает. И в принципе «выигрыш» не стоит искать в явном виде (посмотрите аргументы автора на протяжении всей статьи).
Ну, экшены же по сути дублируются в контроллере-адаптере SymfonyClientController. В них вы вполне можете взаимодействовать с создаваемым объектом Response и навешивать на него заголовки и всё остальное. Идея в том, что только контроллер-адаптер остается связанным с фреймворком, и если вдруг вы решите ваш контроллер перенести на фреймворк, где нет HttpFoundation, то вам надо будет просто реализовать свой контроллер-адаптер, который взаимодействовал бы уже с другим фреймворком.
Я могу вам на это сказать, что выделенные в отдельные файлы конфигурации тоже заметно упрощают восприятие кода в целом. Да, удобно бывает с @Route-аннотациями прямо в контроллере, но точно так же удобно и хранить те же роуты в отдельном конфигурационном файле. Вопрос, во-первых, привычки, во-вторых — проекта.
Позвольте, так ведь автор и не отказывается от каких-либо преимуществ, он наоборот выделяет преимущества неочевидные.
Так, например, очень многие разработчики наследуют свои контроллеры от базового класса, а значит, и от ContainerAware в то время, когда практика выделения контроллеров в сервисы может заметно упростить понимание того, каковы зависимости контроллера.
Прелесть тут в том, что гибкость Symfony дает несколько путей реализации по сути одного и того же функционала, и в зависимости от случая, вы сможете использовать любой из них. Или аннотации, или конфиги; или ContainerAware-контроллеры, или контроллеры как сервисы — выбор всегда за вами, и зависит от вашей задачи.
Ну, насчет чистого PHP вы конечно загнули. Как минимум придется реализовать свой DIC, persistence layer и шаблонизатор.
А про «идиотский подход» — ну так, знаете, автор и не утверждает, что это единственно верный путь разработки, он просто показывает, что типичный уровень связанности в Sf2-приложении совершенно необязателен; хотите — отказываетесь от аннотаций, хотите — от ContainerAware, но никто вас это все сразу делать не обязывает.
Во-первых, на HttpFoundation уже не только Symfony живет, вот, кажется, Laravel тоже на этот компонент переехал. Так что мы уже не от фреймворка будем зависеть, а от компонента фреймворка.
Во-вторых, в третьей статье серии автор рассматривает отвязку и от HttpFoundation тоже, при помощи выделения дополнительной прослойки.
В третьей части автор поясняет свою точку зрения на этот вопрос, скоро я эту часть допереведу, сможете там прочитать. А вообще, обобщая позицию автора, суть тут в том, что разработчик сам по себе начинает лучше замечать зависимости, и ему больше не кажутся «магией» аннотации и конвертеры параметров. Ну и плюс, контроллер-как-сервис очень проще для восприятия, чем ContainerAware-контроллер — все зависимости сразу видно; сразу, например, понятно, нужен ли контроллеру доступ к БД, и если нужен, то к каким репозиториям, и так далее.
Во-первых, зачем питоновская версия вместе с PHP?
Во-вторых, PHP-код старый очень, уже давно есть нативные неймспейсы, Composer и PSR-автозагрузка. Попробую на досуге форкнуть и переписать что ли.
Боюсь, неправильно поняли, там суть в том, что они хотят дефолтную ветку для сборки выбирать. А я хочу через запятую указать список веток, чтобы CI их смерджила в одну временную, и поверх нее уже исполнила все таргеты. Это полезно, если у вас есть, допустим, пять feature-веток, и вам их надо постоянно интегрировать.
Регексп в __call? Хм.
И вместо того, чтобы вынести сложные ситуации в сервисный слой, оборачивать их какими-то магическими путями? Бросайте вы этот Yii.
Нет, с русским текстом серьезных проблем нет — проверил на соседней статье, он только слова местами склеивает. А вот с определением основного текста реально какая-то беда — он начал читать вообще с разрыва абзаца!
А вы пробовали его прямо на этой статье Хабра запускать? Он похоже по-русски не понимает, или разметку не распарсил, но мне вот он зачем-то прочитал свой собственный исходник!
app/config/routing.yml, а инклудится в нем:И что еще важнее, вы вполне можете объявить несколько конфигураций роутинга в рамках одного бандла, либо точно так же инклудить другие конфиги при помощи
resource.Получается, что в пути
src/My/AcmeBundle/resources/configмогут быть, например, сразуrouting_front.ymlиrouting_admin.yml, импортируемые вapp/config/routing:@Routeэкшенам. А если вы вдруг, например, захотите во всех экшенах суффикс_listзаменить на_index, например? Или, например, для всех рутов с суффиксом_newограничить методы толькоPOST'ом?Имхо, куда удобнее будет сделать изменения в одном или нескольких
routing.ymlи получить красивый и аккуратный коммит, по changeset'у которого явно видно, что он касается только роутинга, нежели получить изменения в большинстве, а то и во всех контроллерах.Кстати, это еще один аргумент за конфиги и против аннотаций.
SymfonyClientController. В них вы вполне можете взаимодействовать с создаваемым объектомResponseи навешивать на него заголовки и всё остальное. Идея в том, что только контроллер-адаптер остается связанным с фреймворком, и если вдруг вы решите ваш контроллер перенести на фреймворк, где нетHttpFoundation, то вам надо будет просто реализовать свой контроллер-адаптер, который взаимодействовал бы уже с другим фреймворком.@Route-аннотациями прямо в контроллере, но точно так же удобно и хранить те же роуты в отдельном конфигурационном файле. Вопрос, во-первых, привычки, во-вторых — проекта.Так, например, очень многие разработчики наследуют свои контроллеры от базового класса, а значит, и от
ContainerAwareв то время, когда практика выделения контроллеров в сервисы может заметно упростить понимание того, каковы зависимости контроллера.Прелесть тут в том, что гибкость Symfony дает несколько путей реализации по сути одного и того же функционала, и в зависимости от случая, вы сможете использовать любой из них. Или аннотации, или конфиги; или ContainerAware-контроллеры, или контроллеры как сервисы — выбор всегда за вами, и зависит от вашей задачи.
А про «идиотский подход» — ну так, знаете, автор и не утверждает, что это единственно верный путь разработки, он просто показывает, что типичный уровень связанности в Sf2-приложении совершенно необязателен; хотите — отказываетесь от аннотаций, хотите — от ContainerAware, но никто вас это все сразу делать не обязывает.
Во-вторых, в третьей статье серии автор рассматривает отвязку и от HttpFoundation тоже, при помощи выделения дополнительной прослойки.
evalнапример): github.com/kix/mdashА тут бандл симфонийский: github.com/kix/mdash-bundle
Во-вторых, PHP-код старый очень, уже давно есть нативные неймспейсы, Composer и PSR-автозагрузка. Попробую на досуге форкнуть и переписать что ли.
И вместо того, чтобы вынести сложные ситуации в сервисный слой, оборачивать их какими-то магическими путями? Бросайте вы этот Yii.