RAD - Rapid Application Development, разве нет? На Yii2 действительно очень удобно накидать proof of concept и MVP вместе с веб-интерфейсом на бутстрапе. Но что-либо большее - это уже жесть, надо сразу выкидывать и переделывать норм)

а ещё Rad - это "велосипед" на немецком это что - то да значит...

а я еще RUP помню

RAD - Rapid Application Development, разве нет? На Yii2 действительно очень удобно накидать proof of concept и MVP вместе с веб-интерфейсом на бутстрапе. Но что-либо большее - это уже жесть, надо сразу выкидывать и переделывать норм)

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

в таком ключе

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

кто-кто. юишники конечно

класические сайтики все еще рулят

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

я накидываю, мне это проще. Да и еще процентов 80 php разработчиков :)

я накидываю, мне это проще. Да и еще процентов 80 php разработчиков :)

Вот это заявление. А можешь предоставить метод, которым ты определил долю из всех пхпшников?

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

Типа делать MVP на SPA + REST бэкенд/GraphQL быстре чем нахлопать на RubyOnRails?

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

Вот это заявление. А можешь предоставить метод, которым ты определил долю из всех пхпшников?

triggered

triggered

Процентов 99 Богданов именно так и реагируют на подобные сообщения :)

от проекта зависит ну и меня ещё бесят симфони формы, это да)

Вы еще не забывайте, что WP - это топ1

Типа делать MVP на SPA + REST бэкенд/GraphQL быстре чем нахлопать на RubyOnRails?

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

Типа делать MVP на SPA + REST бэкенд/GraphQL быстре чем нахлопать на RubyOnRails?

Сейчас сложно представить не API-first подход. С норм апи у тебя вообще нет никаких проблем ни со спа ни со статикой ни с чем

Сейчас сложно представить не API-first подход. С норм апи у тебя вообще нет никаких проблем ни со спа ни со статикой ни с чем

Стартап / MVP с нормальным API ?

Опять таки, советую свеженький доклад на тему "SPA vs Стат.Страницы" https://t.me/oop_ru/70064

схоронил но все равно выступаю за it depends Вероятно, потому, что все идеи, которые есть у меня, довольно завязаны на фронт

Так прототип на каком-нибудь next.js накидывать одно удовольствие кмк)

Или rogue, но последний еще не тыкал

Типа делать MVP на SPA + REST бэкенд/GraphQL быстре чем нахлопать на RubyOnRails?

в целом не медленнее. Но мы про рельсы не говорили

Или rogue, но последний еще не тыкал

как его гуглить?)

находит всякую фигню

кто-кто. юишники конечно

Не не, они накидывают не прототипы, в этом беда)

как его гуглить?)

https://github.com/alidcastano/rogue.js

спасибо по запросу rogue.js кидало ссылки на вирустоталы всякие ?

Простите за некоторый оффтоп: кто-то сталкивался с ошибками типа UndefinedClass при использовании Psalm? Очевидно, Psalm не может подгрузить классы, хотя судя по документации должен уметь работать с автозагрузчиком Composer

тебе в другой чат

Простите за некоторый оффтоп: кто-то сталкивался с ошибками типа UndefinedClass при использовании Psalm? Очевидно, Psalm не может подгрузить классы, хотя судя по документации должен уметь работать с автозагрузчиком Composer

https://github.com/vimeo/psalm/search?q=UndefinedClass&type=Issues

и да - это оффтоп

Сорри. Исправлюсь

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

Хорошо, просмотрю issues и напишу в другой чат, если не найду решения. Спасибо

Добрый день, есть консольная команда, которая дергает методы сервиса, нужно, чтобы дополнительная инфа для отладки выводилась, додумался сделать декоратор, но на сколько это вообще законно/адекватно?)

иногда еще AOP юзают

иногда еще AOP юзают

Гугл на всё связанное со Spring кидает, я на ПиЭйчПи сейчас сижу - у меня лапки)

Гугл на всё связанное со Spring кидает, я на ПиЭйчПи сейчас сижу - у меня лапки)

https://github.com/goaop/framework

Гугл на всё связанное со Spring кидает, я на ПиЭйчПи сейчас сижу - у меня лапки)

https://t.me/prophp7/116530 тут обсуждали недавно

как по-трушному маппить данные из ДТОшки на сущность? 1. сеттеры - зло 2. метод update с кучей параметров - один большой сеттер (хотя в определенных ситуациях имеет место быть) 3. метод update с DTO в параметре - та же ситуация + просачивание приложения в домен (если DTO относится к приложению, что тоже спорно) для чистоты допустим, что update - вполне обоснованная бизнес-логикой операция, а не crud

пацаны, что вы болше любите форич или аррэй мап?))

пацаны, что вы болше любите форич или аррэй мап?))

не тот чат Артур

как по-трушному маппить данные из ДТОшки на сущность? 1. сеттеры - зло 2. метод update с кучей параметров - один большой сеттер (хотя в определенных ситуациях имеет место быть) 3. метод update с DTO в параметре - та же ситуация + просачивание приложения в домен (если DTO относится к приложению, что тоже спорно) для чистоты допустим, что update - вполне обоснованная бизнес-логикой операция, а не crud

инжектишь дто и берешь геттерами данные, не?

вроде в этом суть

инжектить в сущность? update(dto: DTO) так?

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

падажжи, обычно должно работать как то так: контекст (entity) вызывает какой то метод. Метод возвращает DTO, а ты из DTO уже берешь что нужно

не?

давай псевдокодом, я не совсем понял твой вариант

у меня команда "обнови сущность"

ну тогда где то на уровень выше инжекти дтошку туда, имхо

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

дтошка уже приходит внутри команды

Как по мне update(dto: DTO) норм вариант

Ток вот дело в том что обычно тут стоит задуматься, а DTO ли это у тебя или часть домена

так же как и команда

ещё, кстати, нюанс в том, где иногда команда - тоже дто и тоже несёт данные

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

ERROR: S client not available

Ток вот дело в том что обычно тут стоит задуматься, а DTO ли это у тебя или часть домена

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

https://github.com/goaop/framework

Чёрт, АОР - круто! Сейчас вводную статью на хабре прочитал от автора фреймворка этого, просто заразился, просто в голове вопросы "А ЧТО, МОЖНО ВОТ ТАК ПРОСТО"?

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

вот я и пытаюсь понять, что я не так делаю)

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

А ты на практике или просто по примеру кода?

это я по protected

Ну может углы срезал автор, идеального ничего нет)

это я по protected

protected методы это терпимо, категорически плохо только protected поля

@fes0r задвинь еще свое мнение по моему вопросу

а чем плохи protected поля ?

а чем плохи protected поля ?

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

вот если бы у тебя стэйта небыло (имутабельность) то тогда норм

чтобы несколько проапдейтить: 1. допустим, есть сущность Location и dto для LocationData 2. как маппить данные LocationData на Location? (LocationData проходит путь от формы до хендлера команды) 3. а что, если все поля команды - уже поля, которые должны попасть в сущность?

чтобы несколько проапдейтить: 1. допустим, есть сущность Location и dto для LocationData 2. как маппить данные LocationData на Location? (LocationData проходит путь от формы до хендлера команды) 3. а что, если все поля команды - уже поля, которые должны попасть в сущность?

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

это по 3 пункту?

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

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

угу, тоже чесалось такое

дто для Location сделано только для целей "не класть сущность в форму" ну и для композиции - т.к. Location используется много где

дто для Location сделано только для целей "не класть сущность в форму" ну и для композиции - т.к. Location используется много где

а какое поведение у сущности? зачем она? может быть тебе она не нужна?)

может ли Location меняться?

меняться может я уже думал про embedded, но: 1. много менять 2. иногда две сущности ссылаются на одну location

меняться может я уже думал про embedded, но: 1. много менять 2. иногда две сущности ссылаются на одну location

тут первый пункт все варианты загубит)

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

либо забил бы

не особо болит

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

ну это да, пока не болит болит маппить команды на сущности)