ну тип того, в контроллере будет что-то типа return new Item($product, new ProductListItemTransformer());

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

ну и у меня еще пара безумных идей в духе

return new ProductListRepresentation();

а внутри этой хрени будет описано как сгенерить dql, который сфетчит массивчик

что бы сущности в целом не грузились

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

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

пхпшторм умеет такое

Рефракторинг

оуу, круто как?

https://www.jetbrains.com/help/phpstorm/2016.2/refactoring-source-code.html

Refactor -> Rename

или Refactor -> Move если нужно неймспейс еще сменить

оуу, круто как?

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

всякие шорткаты типа pubf вместо написания целиком

генерация методов, полей

пхпдоков

штуки с дебаггингом

спасибо, просто не нужно было рефакторить симфони еще, вот и не сталкивался)

я лайв темплейты себе настроил - так вообще збс

пишешь it и тебе funtion it_$() {} генерится

а если есть неявное обращение в твиге он же не найдет наверное

а если есть неявное обращение в твиге он же не найдет наверное

смотря насколько неявное

ну в контроллере делается find всех полей

ну с учетом того что информация о типах теряется - врядли

а в твиге client.name

тип для client потерян же

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

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

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

ну мол... я сейчас планирую писать аналог элоквента для доктрины)))

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

или вообще на массивы

только для чтения конечно

read model для доктрины типа

ну и да

если у тебя в сущностях будут геттеры и сеттеры - то как бы толку тоже нет

@fes0r а ты не знаешь либы для гидрации выборки из sql в структурки?

если тебе надо тупо массив на объект насодить - zend hydrator и есть окромиусовский generated hydrators

а если надо plain на дерево объектов... увы не знаю... сам ищу

был paper

выборку из SQL на массив ну или на DTO

с коллекциями, с присоединёнными сущностями

массив на массив - вот неплохой - https://github.com/ScriptFUSION/Mapper

массив на объекты... знаю только 1:1 который мэпит без изменений в структурах

https://github.com/cweiske/jsonmapper

в целом в свое время пробовал https://github.com/idr0id/Papper

а если надо plain на дерево объектов... увы не знаю... сам ищу

да, plain на дерево объектов, как ArrayHydartor доктрины

сейчас его и использую, немного пропатчил, т.к. он был завязан на ORM (entity manager, class metadata)

https://framework.zend.com/manual/2.4/en/modules/zend.stdlib.hydrator.html

ну из того что вменяемое есть

так его можно заюзать для гидрации plain выборки SQL с fetch-join'ами, коллекциями и т.п

?

или это маппинг массива на объект со схожей структурой?

$statement = $this->connection->prepare(' SELECT book.isbn AS book_isbn, book.name AS book_name, author.id AS author_id, author.name AS author_name, category.id AS category_id, category.name AS category_name FROM author LEFT JOIN book ON book.author_id = author.id LEFT JOIN category ON book.category_id = category.id '); $statement->execute(); $authors = $this->hydrator->hydrateAll($statement, $rsm); http://i.prntscr.com/95c3a0f45fbb44a894c7b55f8e72dd62.png такое вот

Бля окрамиус опять жгет в твиттере

https://twitter.com/ocramius/status/806837281973792768

Весь тред просто легендарен

ооо, борис

меня шведы долго заебывали борисом)

how to squat like a slav :D

Почитай там всю конву сначала для контекста

Огонь

?

это уж совсем не по теме флуд

а я и не знал что егор java/php разраб

php?

серьезно?

да) в амстердаме пока работал писал и на том и на том

но вообще в джаву типа из пхп перешел

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

насколько вообще адекватна идея вложенных объектов в контексте DTO?

я вот чет думаю думаю и не могу пока придумать "чем плохо"

ну вообще норм

а не смотрел в сторону симфони сериализатора?

хотя не то

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

ну хз даже. а че зендовый гидратор умеет? а то я не помню уже

ну он умеет гидрировать

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

)

но из коробки он рекурсивно собирать объекты не умеет

хотя возможность такую дает, просто неудобно

хм... может реально symfony serializer потыкать

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