Но по возможности я бы работал через репу

спасибо, тоже так думаю

сорри за оффтопик Ищем Middle-Senior / Senior PHP (Symfony) Developer в Одесский филлиал большой американской компании. Помощь в релокейте, высокие зарплаты, работа долгосрочная. Скайп: aurosonique

выборка, которую хочу напрямую через PDO сделать, без доктрины. Лучше в репозиторие сделать или отдельным сервисом? Просто хуливар возник с коллегой. Имхо это в репе делается

Я бы не работал через репо

Я бы не работал через репо

Я может соглашусь, просто пока не вижу причин. Вы можете сказать почему? Для меня интуативно понятно, что если есть выборка из БД, то искать надо в репе, не зависимо от того что она возвращает(dto, массив dto или кастомный массив)

Здравствуйте. Подскажите, как подключить формы из SyliusUi в AppBundle?

При подключении в твиге формы {% form_theme form '@SyliusUi/Form/theme.html.twig' %}

Получаю ошибку Variable "form" does not exist.

Возможно, её необходимо зарегистрировать, но где?

Я может соглашусь, просто пока не вижу причин. Вы можете сказать почему? Для меня интуативно понятно, что если есть выборка из БД, то искать надо в репе, не зависимо от того что она возвращает(dto, массив dto или кастомный массив)

да очень много методов получается, и каждый из них чаще всего используется в одном месте

ну и репо с сущностями работает

мне нравится идея делигировать это дело на объект представляющий выборку

сорри за оффтопик Ищем Middle-Senior / Senior PHP (Symfony) Developer в Одесский филлиал большой американской компании. Помощь в релокейте, высокие зарплаты, работа долгосрочная. Скайп: aurosonique

ех одесса, где ты был года 3 назад )

какого черта symfony хочет что бы при прогреве кэша у меня уже были env переменные?

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

Я может соглашусь, просто пока не вижу причин. Вы можете сказать почему? Для меня интуативно понятно, что если есть выборка из БД, то искать надо в репе, не зависимо от того что она возвращает(dto, массив dto или кастомный массив)

Репозиторий это коллекция сущностей, поэтому методы для выборок "несущностей" имеет смысл держать не в них

Репозиторий это коллекция сущностей, поэтому методы для выборок "несущностей" имеет смысл держать не в них

$collection->count()

$collection->filter($myCriteria)->sum()

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

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

Ну так можно и map добавить)

И reduce

ребята кака рахница между следующими способами задания аргументов

arguments: - AppBundle\Utils\HasGeneratorInterface: '@app.hash_generator' Doctrine\ORM\EntityManager: '@doctrine.orm.entity_manager'

app.link_deleter: class: AppBundle\TinyLink\LinkDeleter arguments: ['@doctrine.orm.entity_manager:getRepository']

arguments: - AppBundle\Utils\HasGeneratorInterface: '@app.hash_generator' Doctrine\ORM\EntityManager: '@doctrine.orm.entity_manager'

это что-то странное ты пытаешься сделать в аргументах

а что странного?

http://symfony.com/doc/current/service_container/service_locators.html

отсюда брал пример

Ребята, всем привет Меня тут заставили задуматься по Domain Layer и Persistence Layer + Specification Doctrine Pattern. По-сути, я вот например использую Happyr/Doctrine-Specification И тут мне говорят, что подобные правила в спецификациях - это должно относиться к Domain Layer, а сами спецификации, будучи QueryBuilder-ом по-сути, лезут в Persistence Layer.

Ребята, всем привет Меня тут заставили задуматься по Domain Layer и Persistence Layer + Specification Doctrine Pattern. По-сути, я вот например использую Happyr/Doctrine-Specification И тут мне говорят, что подобные правила в спецификациях - это должно относиться к Domain Layer, а сами спецификации, будучи QueryBuilder-ом по-сути, лезут в Persistence Layer.

с точки зрения ддд они правы

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

Ребята, всем привет Меня тут заставили задуматься по Domain Layer и Persistence Layer + Specification Doctrine Pattern. По-сути, я вот например использую Happyr/Doctrine-Specification И тут мне говорят, что подобные правила в спецификациях - это должно относиться к Domain Layer, а сами спецификации, будучи QueryBuilder-ом по-сути, лезут в Persistence Layer.

Вообще да, твоя доменная область должна быть отделена от инфраструктуры, чтобы не захломлять доменную логику. Как вариант в спецификациях можно держать только expr объекты - грубо говоря dsl, а все инфраструктурые штуки, например join, group by или через аннотации или через декораторы

Ну у тебя будет класс спецификации на domain layer и его декоратор на persistence layer

Ещё бы не плохо сказать про недостатки

Чрезмерная декомпозиция

Нужно хендлить кучу классов и тп

ну тип того. Смотри, у тебя есть Domain Layer: - сущности - интерфейс репозитория (публичная реализация) - спецификации (в идеале у тебя у сущности есть метод isSutisfiedBy)

Чрезмерная декомпозиция

на самом деле это как сделаешь так и будет

ну то есть то что мы с тобой замутили - это вообще трэш)

идеальный пример - спецификации в контексте Doctrine/collection

когда у тебя есть просто у "коллекции" возможность реализовать спецификацию так как тебе хочется

то есть если тебе надо делать join - то это не особо подходит к вопросу спецификаций... во всяком случае я пока такой идеи придерживаюсь

Happyr/Doctrine-Specification - неплохая штука но это больше все же инфраструктура

которую можно использовать в контексте твоих спецификаций

Нужно хендлить кучу классов и тп

на самом деле это не особо большая проблема

больше вопрос именования)

Max, @fes0r, как примерно выглядит спецификация в предметной области?

как VO примерно, просто какой-то объект с какими-то данными.

а дальше можно по всякому, это и visitor pattern и прочие штуки

а есть пример?

а есть задача конкретная?

спецификация определяется в предметной области, а как её в инфраструктурном слое применять?

книга определённого автора

это подходит под задачу на спецификации?

Book::isSatisfiedBy(AuthorSpecification $spec)

return $spec->visitAuthor($this->author);

AuthorSpecification implements BookSpecification

interface BookSpecification visitAuthor(Writer $author); visitSomething(..)

ну а потом $books->matching(new DoctrineAuthorSpecification($anAuthor)); // из репозитория

аа, вот, это декоратор для AuthorSpecification

это имеется ввиду?

спецификация определяется в предметной области, а как её в инфраструктурном слое применять?

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

это имеется ввиду?

тип того. Тут нет именно декорации - просто разные реализации.

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

ERROR: S client not available

> $books->matching(new DoctrineAuthorSpecification($anAuthor)); // из репозитория вот эта штука строго внутри реализации репозитория. Репозитории - они типа на границе между слоем предметной области и инфраструктурой. То есть интерфейс мы определяем в слое предметной области а имплементация уже в инфраструктуре.

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

главное что бы за пределы репозитория инфраструктура не вылазила

всем доброго времени суток

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

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

можно это как-то сделать?

в документации не могу найти

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

заходи в цикл, и чекай статус процесса

можно это как-то сделать?

на PHP типа?

средствами symfony

вообще в линуксах всяких ты можешь отслеживать как любой отдельный pid так и вообще все дочерние

черезй wait

так что копай в эту сторону

Парни, как лучше всего превратить PersistentCollection полученный из связи oneToMany в массив массивов или json?

И можно ли передать както Symfony\Component\HttpFoundation\Request в параметр сервиса? или то тчо работает с реквестом не может быть сервисом, и это должно в контроллере обрабатываться? ПРосто делаю сервис RequestInfoExtractor который будет получать геоинформацию и браузер пользователя, вот пока не решил как его лучше юзать

Короче сделаю его stateless и буду передавать Request в каждый метод

Парни, как лучше всего превратить PersistentCollection полученный из связи oneToMany в массив массивов или json?

https://symfony.com/doc/current/components/serializer.html

И можно ли передать както Symfony\Component\HttpFoundation\Request в параметр сервиса? или то тчо работает с реквестом не может быть сервисом, и это должно в контроллере обрабатываться? ПРосто делаю сервис RequestInfoExtractor который будет получать геоинформацию и браузер пользователя, вот пока не решил как его лучше юзать

https://symfony.com/doc/current/service_container/request.html

Большое спасибо!

Парни как правильно обработать дату в контроллере в лучших традициях

я сделал вот так:

if (!empty($expiredDateParam)) { $expiredDate = DateTime::createFromFormat('Y-m-d', $expiredDateParam); if ($expiredDate === false) { throw new Exception('Incorrect date format'); } } else { $expiredDate = null; }

естественно это хуево

вопервых избавимся от else: $expiredDate = null; if (!empty(expiredDateParam)) { // }

во вторых делаем валидацию данных на входе: $rules = new Collection([ 'expiration_date' => new Optional(new Date()), ]); $errors = $validator->validate($data, $rules); if ($errors->count() !== 0) { // error response }

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

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

'expiration_date' => new Optional(new Date()), тут проблема что если передать некорректную строку он создаст текущуб дату

вопервых избавимся от else: $expiredDate = null; if (!empty(expiredDateParam)) { // }

+

Добрый день. После выполнения команды $this->render('@FrontBundle/Hello/buy.html.twig) почему то симфони начинает искать тимплейт в (looked into: /home/alex/Documents/Work/repo/vendor/symfony/twig-bridge/Resources/views/Form