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

кастомный лоадер слабо впишется он должен добавлять роуты в саму симфони, а я думал обойтись без прописывания spa-роутов в ней

а так да, в 2005-ом каком все от этого нащились

я не нашел пруфов что в 2018-ом это хоть на что-то влияет)

ну вообще это мало ебет сеошников и заказчиков

что я найду или нет

есть требования жеже

https://www.hobo-web.co.uk/search-engine-friendly-urls/

пока лютый ад с тем что-бы парсить самому воженность секций приходит в голову

я бы вот эту статью скинул)

https://www.hobo-web.co.uk/search-engine-friendly-urls/

срать они хотели на статьи) это же заказчики, друх. Я студийщик

ну короч регулярки твои друзья

регулярки тоже не друзья =(

ты однозначно регулярками не определишь секция или код книги у тебя

при том грузить лоадером тоже уныло, ибо секций и книг - овердохера

так что чую приложить на 1 роут, который кастомно разроутит уже все-таки пока самое живое решение =(

ты однозначно регулярками не определишь секция или код книги у тебя

book_details: path: /books/{section_codes}/{book_code} requirements: section_code: .+ defaults: {...}

кастомный лоадер слабо впишется он должен добавлять роуты в саму симфони, а я думал обойтись без прописывания spa-роутов в ней

spa роуты, Single PAge app routes? Создаешь в роутах resource: . type: spa в конце еонфига. Создаешь свой лоадер там пишешь что то типа тип spa. ставишь routing.yml в конце конфига/ чтобы все адреса которые не вошли в основной роутинг обрабатывались своим контроллером

book_details: path: /books/{section_codes}/{book_code} requirements: section_code: .+ defaults: {...}

а так нельзя писать? Будет определять, что именно является book_code

низя...

ибо есть еще страница секции

еще есть страница рутовой секции(но это уже частность)

еще есть страница рутовой секции(но это уже частность)

с секциями тоже самое

section: path: /books/{section_codes}/{section_code} requirements: section_codes: .+ defaults: {...}

У тебя даже пути есть path: /books/{section_codes}/{book_code}

/books/{section_codes}/{book_code} = /books/{section_codes}/{section_code}

Всегда такая проблема существует, добаляй префикс

то есть, в секциях не books, а sections в начале

то есть, в секциях не books, а sections в начале

для префикса

эх... я бы рад что-то добавлять

но повторю. мне просто дали урлы

и сказали - делай, посан

У тебя путь /books/{section_codes}/{section_code} ИЛИ /books/section_{section_codes}/book_{section_code}

тогда Вам нужно что-то вроде PHPCR - Content repository

spa роуты, Single PAge app routes? Создаешь в роутах resource: . type: spa в конце еонфига. Создаешь свой лоадер там пишешь что то типа тип spa. ставишь routing.yml в конце конфига/ чтобы все адреса которые не вошли в основной роутинг обрабатывались своим контроллером

насколько я понял доку по нему - лоадер должен вернуть коллекцию роутов, которые будут доступны

вида new Route($path, $defaults, $requirements);

то есть, для всех ресурсов будет один роут, а какой именно ресурс определяет уже контроллер

насколько я понял доку по нему - лоадер должен вернуть коллекцию роутов, которые будут доступны

Да стандартная регулярка симфони

то есть, для всех ресурсов будет один роут, а какой именно ресурс определяет уже контроллер

Так собственно и сделал

то есть, для всех ресурсов будет один роут, а какой именно ресурс определяет уже контроллер

Просто думал мб можно как-то еще

возвращаться из контроллера в пулл роутов например

Это может быть любая страница .+

Да стандартная регулярка симфони

так я ведь не знаю, какие роуты у меня будут в спа) точнее, не хочу прописывать их где-то в ней разве что повесить какой-то роут типа /.* и бросать на точку входа spa и отдать уже ему обработку 404 ошибки

есть еще такой вариант

book: path: /books/{section_codes}/{book_code}.html requirements: section_codes: .+ defaults: {...} section: path: /books/{section_codes}/{section_code}/ requirements: section_codes: .+ defaults: {...}

Тоже такое делал

но там регулярка посложнее

section_root: path: /books/{section_code}/ requirements: section_codes: .+ defaults: {...}

section_root: path: /books/{section_code}/ requirements: section_codes: .+ defaults: {...}

это для корневой секции

@Route("/{path}/", requirements={"path"="[^\.]+(?!\.html)$" })

что-то из такого раздела

ибо .+ пожрет и .html

не пожрет, можно добиться нужного, просто написав в нужном порядке

с нужными названиями, да

в нужном порядке

что-бы отсортировало по названию в нужном порядке

но ввиду каталога и неизвестного кол-ва доработок вроде /books/{landing_url}/

Очень жалею, что нет приоритетов в симфони для роутов

Но жизнь боль, потому усложняем регулярки и пишем контроллеры-роуты

просто Вам нужно написать роуты не в Аннотациях, а в yaml файле routes.yaml

там уже порядок роутов имеет значение

Мне просто кажется, что такое решение скорее костыль, как и контролер-роутер

при том контроллер-роутер сам себя документирует, а вот yml и почему вот он нужен именно - уже нужно где-то описать и ознакомить окружающих

раньше приложения и без аннотации писали...

Раньше на перфокартах программировали

надеюсь поняли мою мысль =))

Очень жалею, что нет приоритетов в симфони для роутов

Cmf routing реализовал такую возможность

https://symfony.com/doc/current/cmf/book/routing.html#the-chainrouter

ERROR: S client not available

там уже порядок роутов имеет значение

Я тоже думаю что этого достаточно

@Route("/{path}/", requirements={"path"="[^\.]+(?!\.html)$" })

или обойтись роутингом в аннотации с регуляркой

при том контроллер-роутер сам себя документирует, а вот yml и почему вот он нужен именно - уже нужно где-то описать и ознакомить окружающих

тебе нужно избежать не ок кода, или чтобы красивенько лежали конфиги?

тебе нужно избежать не ок кода, или чтобы красивенько лежали конфиги?

мне нужно избежать и не ок код и так то-бы было документированно

извиняюсь за глупый вопрос, но что значит "ок код"?

combot.org/chat/-1001091570538

http://symfony.com/blog/the-end-of-the-symfony-standard-edition

https://medium.com/@fabpot/symfony-4-unpack-the-packs-a672d06850eb

composer unpack laravel)))

Ребят не ради холивара. Почему Symfony а не Laravel? Нужно хотябы пару тезисных аргументов. Кто может помочь их найти и описать?

тейлор неадекват, фабиен няшка лару пишет один герой, симфони целая команда, за которой стоит компания ну и лара сделана поверх компонентов симфони

тейлор неадекват, фабиен няшка лару пишет один герой, симфони целая команда, за которой стоит компания ну и лара сделана поверх компонентов симфони

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

ну а дальше твои пункты

ну и сообщество как по мне на симфони адекватнее

на ларе как-то слишком токсично

подождем еще годик-два и половина адекватного симфони сообщества станет писать на котлинах и го

все мои знакомые уже перешли(

Потому что на симфони ты вырастаешь из ПХП разраба в нечто большее?

в разраба да)

но симфони тут постольку поскольку

Ну симфони просто неплохо имплементит в себя хорошие принципы.

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

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

Какие жирные плюсы можно подметить у последней версии Symfony?

DI и DX)

ну и сама философия

DI - давно не жирный плюс

тот которым он стал, это жирный плюс

если сравнивать с тем что было до 2.8 версии к примеру

DI - давно не жирный плюс

у симфони - вполне себе жирный

у симфони - вполне себе жирный

Ожил

Посмотри мою стратегию )