А почему requirements не работает? Покажи код.

Потому, что requirements не для параметров GET.

Как это не для GET? У меня и для GET и для POST и для ANY всё раоботает :)

requirements нужен для ограничений на параметры маршрута. GET-параметры не являются частью маршрута.

requirements нужен для ограничений на параметры маршрута. GET-параметры не являются частью маршрута.

А ну да :)

Просто не надо путать /some/path/{param} и /some/path?param.

Просто не надо путать /some/path/{param} и /some/path?param.

Согласен. Перепутал. Просто ещё не проснулся :)

Во втором варианте это query string

т.е. только в контроллере проверять

Чтобы у тебя заработали requirements, тебе нужно сделать /categories/{page}/{limit}. Но это корявенько очень.

мне Get нужны)

так не подходит

Параметры GET ты там не ограничишь.

По идее GET-параметры - это не обязательные параметры. Их же не надо ограничивать. Их надо проверять на валидность.

А это можно сделать через EventListener

да спасибо, тоже склоняюсь к EnentListener'у

event.kernel_controller, вроде так.

event.kernel_controller, вроде так.

спасибо

Все видеозаписи за 5 последних лет HighLoad++ теперь в ОТКРЫТОМ доступе: https://www.youtube.com/user/profyclub/

Дурдом... MVP делался хаотично, на базе старой архитектуры, и теперь реально стоит вопрос... выделять время (полгода) на переписывание все с нуля, или продолжать костыли писать всем взводом?

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

Дурдом... MVP делался хаотично, на базе старой архитектуры, и теперь реально стоит вопрос... выделять время (полгода) на переписывание все с нуля, или продолжать костыли писать всем взводом?

пол года - много

> но параллельно есть возможность вести разработку чистового продукта. есть риск рассинхрона

Такой запас времени у нас есть по RoadMap...

я не знаю ни одного случая когда такой вариант (пилим паралельно с нуля) сработал

хотя допускаю что это возможно

а в чем ад то?

ну и кастыли

неужто все так плохо?

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

Если честно то да, уже бьет по производительности. Писалось все слишком хаотично и это реальный MVP... )

Если честно то да, уже бьет по производительности. Писалось все слишком хаотично и это реальный MVP... )

что бьет по производительности?

архитектура.

архитектура - это когда у тебя есть ограничения что можно делать и чего нельзя

у тебя нет архитектуры)

архитектура.

давай более предметно

кривая структура базы и неэффективные запросы?

это рефакторится

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

много регрессий

нет тестов

ладно

если делать еще одну библиотеку для работы с очередями

(рассматривал bernard, laravel/queue, swarrot)

что бы такого сделать что бы было прикольно?

ну например... есть вот отложенные сообщения. Типа "выполни задачу через 30 сек"

это месседж должен знать что надо откладывать сообщение или сама очередь в которую мы ложим?

очередь, почему месседж?

ну например

у тебя есть например работа с внешним сервисом который закрыт рэйт лимитом

ты кидаешь объект, а очередьь должна знать че с ним сделать и когда )

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

ты кидаешь объект, а очередьь должна знать че с ним сделать и когда )

ну вот я хз)

сегодня это месседж, а завтра это какая-то еще нотификация, и т.д. и т.п.

если брать какие-нибудь beanstalkd-ы и sqs то они хранят это дело в месседже

что вполне логично

половина всех этих вещей заточены под выполнение какого-то набора примитивов...

не ну так то да

вот я сейчас кручу в голове насколько это будет удобно/неудобно если информация о делее будет храниться в месседже

что такое месседж? может ли вместо месседжа быть команда например на import/export?

это содержимое месседжа

ну мол так же как и с объектами

у тебя "вызов метода" это на самом деле отправка сообщения

окей, тогда что у тебя queue?

коллекция сообщений

с простым интерфейсом

ERROR: S client not available

эммм... тогда недопонимание кажись вышло...

)

ну короч я понял - месседжи всему голова

йап.

только убивал бы за такое определение )

но вот куда они ложатся (тьюб) - это уже дело коллекции

так наверное будет проще

или нет...

а есть какой-нибудь веселый и надежный бандл навроде entrust для симфони? чтобы роли и всё такое в базе хранить, и много руками на ACL не перепиливать.

а есть какой-нибудь веселый и надежный бандл навроде entrust для симфони? чтобы роли и всё такое в базе хранить, и много руками на ACL не перепиливать.

а есть проблемы роли хранить в базе?

ну то есть симфони это умеет из коробки

или ты о чем?

глянул entrust - вроде бы все есть в symfony/security из коробки

мб я не до конца в ACL разобрался, но он вроде user-based был на первый взгляд вообще, без ролей. Нет? Идеальный сценарий: иметь возможность добавлять новые разрешения (может редактировать комментарии, может видеть блок счетов), добавлять роли, назначать ролям разрешения, привязывать пользователям роли и в итоге чекать разрешение как в контроллерах, так и в твиге.

мб я не до конца в ACL разобрался, но он вроде user-based был на первый взгляд вообще, без ролей. Нет? Идеальный сценарий: иметь возможность добавлять новые разрешения (может редактировать комментарии, может видеть блок счетов), добавлять роли, назначать ролям разрешения, привязывать пользователям роли и в итоге чекать разрешение как в контроллерах, так и в твиге.

нет

там можно роли

если это на pure symfony из коробки можно сделать без лишних мучений, то было бы круто и я пойду разбираться.)

мб я не до конца в ACL разобрался, но он вроде user-based был на первый взгляд вообще, без ролей. Нет? Идеальный сценарий: иметь возможность добавлять новые разрешения (может редактировать комментарии, может видеть блок счетов), добавлять роли, назначать ролям разрешения, привязывать пользователям роли и в итоге чекать разрешение как в контроллерах, так и в твиге.

можно сделать на ролях и для особо сложных случаев воутеры

если это на pure symfony из коробки можно сделать без лишних мучений, то было бы круто и я пойду разбираться.)

там в симфони твои юзеры типа должны имплементить UserInterface

и там есть getRoles

это к вопросу "как и где хранить" - решай сам типа

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

и динамически менять

там где надо чето проверить просто просишь

$security->isGranted('EDIT_POST', $post);

например

если логика прям пипец сложная - пишешь воутеры

хм, спасибо, попробуем.

Назревает не очень сложный парсинг прайс-листов, я придумал, как под это дело написать конфиги в YAML. Если я запихну весь конфиг в parameters — это норм или засорение контейнера?

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

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

@skobkin в отдельный yml?