))

а я не пишу аттрибуты, они сами пишутся

Поделись знанием)

Народ ! Симфони 4.4 вываливается с ошибкой

{"message":"Uncaught PHP Exception Symfony\\Component\\Intl\\Exception\\MissingResourceException: \"Couldn't read the indices [Names] for the locale \"favicon.ico\" in \"/application/vendor/symfony/intl/Resources/data/regions\".\" at /application/vendor/symfony/intl/Data/Bundle/Reader/BundleEntryReader.php line 175","context":{"exception":{"class":"Symfony\\Component\\Intl\\Exception\\MissingResourceException","message":"Couldn't read the indices [Names] for the locale \"favicon.ico\" in \"/application/vendor/symfony/intl/Resources/data/regions\".","code":0,"file":"/application/vendor/symfony/intl/Data/Bundle/Reader/BundleEntryReader.php:175","previous":{"class":"Symfony\\Component\\Intl\\Exception\\ResourceBundleNotFoundException","message":"The resource bundle \"/application/vendor/symfony/intl/Resources/data/regions/favicon.ico.json\" does not exist.","code":0,"file":"/application/vendor/symfony/intl/Data/Bundle/Reader/JsonBundleReader.php:39"}}},"level":500,"level_name":"CRITICAL","channel":"request","datetime":{"date":"2023-07-21 20:25:42.387919","timezone_type":3,"timezone":"Europe/Riga"},"extra":[]}

Кто может подсказать почему сифони пытается сделать локаль из favicon.ico ?

Кто может подсказать почему сифони пытается сделать локаль из favicon.ico ?

В какой директории этот файл лежит?

В какой директории этот файл лежит?

/build/assets/public/images/favicon/favicon.ico

У тебя видимо роут пытается распарить локаль из урла а там favicon.ico

Почему-то факикон идёт на симфу

Нде знать бы ещё где это происходит

Просто положи фавикон в папку public

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

Ты скинул ссылку на файл который лежит в папке images

А не в public

Браузер ищет фавикон по урлу /favicon.ico

Плюс у тебя нет регулярки на параметр locale

Была бы симфа бы отдала 404

Ты скинул ссылку на файл который лежит в папке images

Да я лохонул - там npm кладёт нужные файлы в паблик. Все ассеты отдает nginx тока если это не php

Плюс у тебя нет регулярки на параметр locale

Какой регулярки ?

Какой регулярки ?

Ну что локаль хотя бы два символа

У тебя в роут вместо локали попала строка favicon.ico, почитай ошибку

У тебя в роут вместо локали попала строка favicon.ico, почитай ошибку

Имеешь ввиду вот это "Couldn't read the indices [Names] for the locale \"favicon.ico\" ???

Да

Да

vendor/symfony/intl/Resources/data/regions - это про эту папку. Там внутри куча json'ов под каждую локаль

vendor/symfony/intl/Resources/data/regions - это про эту папку. Там внутри куча json'ов под каждую локаль

https://symfony.com/doc/current/routing.html#parameters-validation

народ хелп - у меня сервак висит на localhost:8000, на одном роуте функция path(route_name) в twig опускает порт и выходит ссылка вида localhost/en/to-some-url (все ссылки на странице такие). На всех остальных роутах всё в порядке. Куда копать. Роут выглядит таким же как и все остальные. Кеш чистил, интернет читал

народ хелп - у меня сервак висит на localhost:8000, на одном роуте функция path(route_name) в twig опускает порт и выходит ссылка вида localhost/en/to-some-url (все ссылки на странице такие). На всех остальных роутах всё в порядке. Куда копать. Роут выглядит таким же как и все остальные. Кеш чистил, интернет читал

Копать почему ссылка строится абсолютная а не относительная

И по-моему симфа смотрит на заголовок X-Forwarded-Port для абсолютных ссылок

Копать почему ссылка строится абсолютная а не относительная

А как симфони решает какую надо ?

А как симфони решает какую надо ?

Подебажить эту функцию

Привет! На проект нужен фулстек мидл или сеньор с опытом от 5 лет, работы много, работа постоянная. Ваши условия. Резюме в личку.

Всем привет! Подскажите плиз такой момент по Доктрине. Вот есть сущность и у нее я беру связь $purchaseObject->getCharacteristics() Берутся все что есть по этой связи, а как можно добавить условие какое-то? Например взять только активные characteristics по связи

https://symfonycasts.com/screencast/doctrine-relations/collection-criteria

Всем привет! Подскажите плиз такой момент по Доктрине. Вот есть сущность и у нее я беру связь $purchaseObject->getCharacteristics() Берутся все что есть по этой связи, а как можно добавить условие какое-то? Например взять только активные characteristics по связи

Написать свой метод в репозитории

https://symfonycasts.com/screencast/doctrine-relations/collection-criteria

https://www.doctrine-project.org/projects/doctrine-collections/en/stable/expression-builder.html

https://symfonycasts.com/screencast/doctrine-relations/collection-criteria

Не рекомендуется, так как фильтруется из всей уже загруженной коллекции

Не рекомендуется, так как фильтруется из всей уже загруженной коллекции

где написано?

Не рекомендуется, так как фильтруется из всей уже загруженной коллекции

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

Причем в сифони касте как раз написано, что есть фильтр, и вот он как раз грузит все, а потом фильтрует.

где написано?

Сорри, прочитал первый код, увидел только фильтры, оно и грузит все. а внизу критерия. Это по сути те же запросы, но внутри ентити.

Сорри, прочитал первый код, увидел только фильтры, оно и грузит все. а внизу критерия. Это по сути те же запросы, но внутри ентити.

запросы внутри ентити - так себе

почему? там не запросы

Кстати вот интерсный флоу с тем, что надо например 2 критерии паралельно поставить разных (два геттера отдельных). Получается тут 1) или у нас все же пост обработка по готовой коллекции 2) Или это не будет работать, так как базовая коллекция одна и после первого лоадинга, вторая критерия или отработает поверх первой или не отработает вовсе 3) Или коллекция с мэтчем всегда ходит в БД и не сохраняет состояние

почему? там не запросы

а какая то магия? ))

а какая то магия? ))

ну я же пишу критерии а не запросы

не понятна в чем суть претензии

всем спасибо! решил попробовать критерии ))

https://symfonycasts.com/screencast/doctrine-relations/collection-criteria

странно, в прошлой версии каста звучала такая фраза: Organizing the Criteria into the Repository One thing I don't like about the Criteria system is that I do not like having query logic inside my entity. And this is important! To keep my app sane, I want to have 100% of my query logic inside my repository. No worries: we can move it there! https://symfonycasts.com/screencast/symfony4-doctrine-relations/collection-criteria

Кстати вот интерсный флоу с тем, что надо например 2 критерии паралельно поставить разных (два геттера отдельных). Получается тут 1) или у нас все же пост обработка по готовой коллекции 2) Или это не будет работать, так как базовая коллекция одна и после первого лоадинга, вторая критерия или отработает поверх первой или не отработает вовсе 3) Или коллекция с мэтчем всегда ходит в БД и не сохраняет состояние

если верить документации Доктрин, когда загружена вся коллекция, то идет фильтрация на уровне php. если нет, то на уровне sql Filtering Collections Collections have a filtering API that allows to slice parts of data from a collection. If the collection has not been loaded from the database yet, the filtering API can work on the SQL level to make optimized access to large collections. https://www.doctrine-project.org/projects/doctrine-orm/en/2.15/reference/working-with-associations.html#filtering-collections

если верить документации Доктрин, когда загружена вся коллекция, то идет фильтрация на уровне php. если нет, то на уровне sql Filtering Collections Collections have a filtering API that allows to slice parts of data from a collection. If the collection has not been loaded from the database yet, the filtering API can work on the SQL level to make optimized access to large collections. https://www.doctrine-project.org/projects/doctrine-orm/en/2.15/reference/working-with-associations.html#filtering-collections

Но ни слова, когда у нас есть несколько критериев на одно поле

Привет всем! Недавно работаю с symfony. Я всегда что объект должен существовать со всеми обязательными свойствами, переданными через конструктор. Пример: https://pastebin.com/D6hKYxs8. Сейчас работаю примерно c таким кодом: https://pastebin.com/nqQCLVJV - вроде ок, работать можно, но придется делать проверки в каждом методе что property1 установлено. что кажется вообще - не нормально. Подскажите как верно использовать symfony service'ы

Привет всем! Недавно работаю с symfony. Я всегда что объект должен существовать со всеми обязательными свойствами, переданными через конструктор. Пример: https://pastebin.com/D6hKYxs8. Сейчас работаю примерно c таким кодом: https://pastebin.com/nqQCLVJV - вроде ок, работать можно, но придется делать проверки в каждом методе что property1 установлено. что кажется вообще - не нормально. Подскажите как верно использовать symfony service'ы

Так сделайте проперти обязательными, и устанавливайте не через call и сеттеры, а через arguments (вместо calls) через конструктор

Почитайте еще раз доку по сервис контейнеру

Так сделайте проперти обязательными, и устанавливайте не через call и сеттеры, а через arguments (вместо calls) через конструктор

Ога, думал именно об этом. А как быть если мне надо передать, загруженную сущность? например в контроллер через ParamConverter добавляется полностью загружена Entity1 и как мне теперь передать в какой-либо сервис? Ведь сервис создается через DI, и получается приходится либо расчитывать на, то что вначале вызвали метод setEntity1, а потом уже можно вызывать другие методы

Ога, думал именно об этом. А как быть если мне надо передать, загруженную сущность? например в контроллер через ParamConverter добавляется полностью загружена Entity1 и как мне теперь передать в какой-либо сервис? Ведь сервис создается через DI, и получается приходится либо расчитывать на, то что вначале вызвали метод setEntity1, а потом уже можно вызывать другие методы

Звучит как что то неправильное и с di не связанное

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

а сервис через di

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

метод сеттер или для работы с бизнес-логикой?

бизнесовый метод

метод сеттер или для работы с бизнес-логикой?

Сеттеры это уже прошлый век и плохой подход

$completeOrder->do($order)

или команду и ее хендлер, что получше будет

спасибо, ваши описания звучат логично

Да заодно уйдешь от этой ужасной практики одним методом установить значение, а другими методами что-то с этим значением делать

Сеттеры это уже прошлый век и плохой подход

Все хорошо что работает и не придает проблем. Сеттер такой же метод как и все остальные.

Все хорошо что работает и не придает проблем. Сеттер такой же метод как и все остальные.

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

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

Ага, поэтому "если не придает проблем".

Ага, поэтому "если не придает проблем".

Это крайне редко не придаёт проблем

Пихать инкапсуляцию там где она не нужна, не меньшее зло

Пихать инкапсуляцию там где она не нужна, не меньшее зло

Не нужна она только в простейшем CRUD, где не нужны объекты

Не нужна она только в простейшем CRUD, где не нужны объекты

- crud или около crud часто бОльшая часть проекта - живут же программисты и проекты, которые агрессивно отвегают рич модели, и все у них ок по их мнению и проекты работают. Главное понимать что и для чего делается, какой профит, а не следовать слепо тому или иному карго культу

- crud или около crud часто бОльшая часть проекта - живут же программисты и проекты, которые агрессивно отвегают рич модели, и все у них ок по их мнению и проекты работают. Главное понимать что и для чего делается, какой профит, а не следовать слепо тому или иному карго культу

Именно так. Если осознанно используют процедурное программирование с интеграционными тестами для CRUD и объектно-ориентированное с юнит-тестами для Rich, то хорошо. А если слепо всё делают на сеттерах, то это культ наоборот.

Именно так. Если осознанно используют процедурное программирование с интеграционными тестами для CRUD и объектно-ориентированное с юнит-тестами для Rich, то хорошо. А если слепо всё делают на сеттерах, то это культ наоборот.

Есть еще те, кто наоборот, слепо следует инкапсуляции простых объектов, где нечего защищать, создавая бессмысленные методы на групповое изменение пропертей, похожие на реализацию юзкейсов внутри сущности. И вместо простых сеттеров, и их комбинаций в разных кейсах, имеет распухшую сущность, с кучей непонятных методов, цель которых - комбинаторика, просто потому что "я слышал что нельзя сеттеры".

Есть еще те, кто наоборот, слепо следует инкапсуляции простых объектов, где нечего защищать, создавая бессмысленные методы на групповое изменение пропертей, похожие на реализацию юзкейсов внутри сущности. И вместо простых сеттеров, и их комбинаций в разных кейсах, имеет распухшую сущность, с кучей непонятных методов, цель которых - комбинаторика, просто потому что "я слышал что нельзя сеттеры".

я думаю, множество таких заблуждении произошло от недопонимания... есть Clean Architecture от Дяди Боба. Он писал/говорил, что бизнесовые методы должны быть в Entity. И тут заблуждение... что есть Entity? по Бобу, это целый "Слой" ПО. А другие поняли это как Doctrine Entity

я думаю, множество таких заблуждении произошло от недопонимания... есть Clean Architecture от Дяди Боба. Он писал/говорил, что бизнесовые методы должны быть в Entity. И тут заблуждение... что есть Entity? по Бобу, это целый "Слой" ПО. А другие поняли это как Doctrine Entity

Про слой честно говоря, я читаю только от Вас, когда вы ссылаетесь на картинку Clean Architecture. Но там опять же спорно, что на картинке именно слои, а не направление зависимости. entity - это "сущность". Сущность как слой - что то не воспринимается

Основное - это преследование профита. Основной профит в риче - это инкапсуляция. И об этом много подходов говорит: tell don't ask , гексагоналка, агрегат. Но смысл один, лишь разница в микро и макро уровнях - это наличие контрактов и закрытие внутренностей. Опять же под инкапсуляцией подразумевается преследование конкретных целей в конкретном домене, а не просто "все инкапсулируем, потому что есть такое слово и подход", если в общем - поддержание конкретных инвариантов домена .

Даже если мы отказываемся, что doctrine entity это то самое место для инкапсуляции, то все равно нужна какая то закрытая сущность, потому что сервис под это дело подходит слабо, так как сервис stateless должен по хорошему быть. Не может сервис быть агрегатом :)

Я видел где то на просторах стековерфлоу пример, как мапили доктрин сущности на другие доменные сущности. Ну короче максимально сложно выглядит и стоит ли полученный профит сложности перегона - большой вопрос

Про слой честно говоря, я читаю только от Вас, когда вы ссылаетесь на картинку Clean Architecture. Но там опять же спорно, что на картинке именно слои, а не направление зависимости. entity - это "сущность". Сущность как слой - что то не воспринимается

полезные обсуждения)) https://groups.google.com/g/clean-code-discussion/c/mvP_NR2MUPc

Про слой честно говоря, я читаю только от Вас, когда вы ссылаетесь на картинку Clean Architecture. Но там опять же спорно, что на картинке именно слои, а не направление зависимости. entity - это "сущность". Сущность как слой - что то не воспринимается

В общем, в просторах интернета есть путаница между DDD & Clean Architecture...