хм, а что тогда нужно изменить чтобы было сагой

?

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

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

мне кажется, Макс пытается сделать то, что и я делал - свести весь флоу в одно место

мне кажется, Макс пытается сделать то, что и я делал - свести весь флоу в одно место

да, но этот процесс не является транзакцией) как верно заметил другой Макс)

это просто последовательность

не спорю, у меня та же фигня :D

ты уже после первых двух этапов можешь например в суппорт писать

ну то есть ты не обязан до конца доходить

это просто последовательность

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

но все же вопрос на счет Process Manager остался, есть ли смысл выделять сервис для оркестрации всех этих процессов

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

но все же вопрос на счет Process Manager остался, есть ли смысл выделять сервис для оркестрации всех этих процессов

у тебя уже есть workflow компонент)

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

у тебя уже есть workflow компонент)

в топку, там где он юзается

могут. Их можно по разному юзать, но здравый смысл никто не отменял)

там он не нужен от слова совсем

ну то есть не сам воркфлоу, а компонент

ну значит и саги не нужны)

так у воркфлоу фигня в том, что он стейт хранит в одной сущности, у него нет размазанного стейта

так у воркфлоу фигня в том, что он стейт хранит в одной сущности, у него нет размазанного стейта

ну так цель то как раз и избавиться от размазанного стэйта

так и у меня стейт только текущий хранится

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

так у воркфлоу фигня в том, что он стейт хранит в одной сущности, у него нет размазанного стейта

ты можешь в целом все что описал Макс покрыть "статусом" пользователя

это не будет нарушать границы контекста

STATE_WATING_CONFIRMATION, STATE_WAITING_PAYMENT_ACCOUNT

ну значит и саги не нужны)

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

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

вариант со статусами ближе к правде, имхо

@fes0r //SomeAction $workflow = $this->get("state_machine.orders"); if (!$workflow->can($order, 'some_transition')) { throw new Exception(); } $order->doSomeAction($someArgs); $workflow->apply($order, 'some_transition');

это что мне не нравится

в идеале сделать так $order->doSomeAction($someArgs);

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

ибо там каждое действие - это как раз таки транзакция

оно не может "зависнуть" навсегда

а кому еще нужно знать про форклоу кроме ордера?

если думать в рамках саг

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

welcome

друпалер..) обидно как-то звучит)

welcome

спс

Привет всем! Такой вопрос... Id пользователя в соц сети у всех соц сетей постоянный, или некоторые используют временные id-шники? Интересует instagram, google, facebook, twitter

а кто работает с PHPSpec? а как вообще идея того чтобы хранить спеки рядом с классами которые они покрывают? Например в одном каталоге: Product и ProductSpec, Category и CategorySpec - ?

Типо как в ангулярах

в целом мне идея нравится

в java например идея "хранить тесты отдельно" в целом понятна

а в php - не очень

а кто работает с PHPSpec? а как вообще идея того чтобы хранить спеки рядом с классами которые они покрывают? Например в одном каталоге: Product и ProductSpec, Category и CategorySpec - ?

тебе придется тогда конфигурить автолоадер и файлы *Spec исключать из autoload + если юзаешь новый симфони di с автоконфигурацией — исключить их из autodiscovery а то будут твои спеки сервисами.

тоже ризонно

Ребят, вы юзаете declare(strict_types=1) ?

Ребят, вы юзаете declare(strict_types=1) ?

до

до

Чувствуете ли ощутимый эффект при дебаге?

а при чем тут дебаг?

А есть те, кто не юзает?)

.....я

А есть те, кто не юзает?)

5.6 (

но! все потому, что проект переведен с 5.6 и могут всплыть бяки

думаю использовать в новых файлах только

в каком случае его лучше не юзать?

Фу такими быть))

или лучше везде по возможности?

ну я еще не юзаю, да, сорян :\

или лучше везде по возможности?

Всегда, если версия позволяет)

Минусов нет, а шкуру иной раз спасти сможет :)

ERROR: S client not available

Всегда, если версия позволяет)

Позволяет)

Минусов нет, а шкуру иной раз спасти сможет :)

Понял, благодарю) Значит примусь рефакторить

Минусов нет, а шкуру иной раз спасти сможет :)

Например?

Я не стану расписывать чем строгий режим лучше. Это как бы совсем грустно

А причем здесь это?

> шкуру иной раз спасти сможе Например

А причем здесь это?

При том.

Хм... Ты пишешь "шкуру иной раз спасти может", я пишу "например", а ты такой резко " я не стану раписывать чем строгий режим лучше"

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

Да боже, причем здесь вообще это?

Приведи пример, когда оно тебе "шкуру" спасало

Сторонний код/не закрытый тестами, на результаты которого мы надеемся. В любом проекте минимальный факап стоит дохера денег. Ну если ток не какой-нить сраный битрикс/маджента) где в принципе насрать. И, да, всё, что я написал ранее - при том.

Я перестал тебя понимать

Если ты ожидаешь от функцит возврат статуса 0, а прилетает '0' - код не работает

И не поймёшь, судя по всему)

Если ты ожидаешь от функцит возврат статуса 0, а прилетает '0' - код не работает

Я так и думал

Если ты можешь использовать declare(strict_types=1), то можешь позволить себе и public function name(): int {}

В чем проблема? :)

Судя по всему в том, что читать кое кто не научился)

Возможно :)

?

Но сути это не изменит

Ты говоришь о типах

Если ты будешь использовать type hinting и у тебя будет int, то тебе не вернется '0'

Гениально

Бывает

Хм... Ты пишешь "шкуру иной раз спасти может", я пишу "например", а ты такой резко " я не стану раписывать чем строгий режим лучше"

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

Ты так и не понял куда влез, да?)

смысл строго режима в том что бы компайл тайм вывод типов не отличался от рантайма. А так как все это работает на уровне отдельного файла - у тебя есть гибкость.

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

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

Дык про режим я и не спорил :) Но он сказал > Если ты ожидаешь от функцит возврат статуса 0, а прилетает '0' - код не работает http://sandbox.onlinephpfunctions.com/code/af984c0523b968d5c53ebafb52c118159c0c9c90