KP
Идеология RestApi, к стати заставляет отказаться от кук и сессиий.. По началу тяжело, но потом становится легко ))))
Собственно сейчас вообще не пользуем сессии.
Каждый запрос не зависит от других.
Size: a a a
2016 November 05
DM
Собственно я их вообще не использую последнее время... даже для аутентификации ;)
KP
Ага... а потом счастливых часов дебага - кто бросает сообщение, где это место найти и какая сука это сообщение перезатерла
Нет.
Сообщения как правило отличаются. Так, что просто поиск по коду бытро показывает где сообщение попало в стэк сообщений. Счет идет на минуты.
Сообщения как правило отличаются. Так, что просто поиск по коду бытро показывает где сообщение попало в стэк сообщений. Счет идет на минуты.
DM
ага, и почему это сообщение выводится совсем на другой стадии, потому-что кто-то не вынул это сообщение
DM
а потом окажется, что один компонент выводит совершенно валидное сообщение, но есть второй компонент, который тоже выводит сообщение, но должен убрать сообщение первого, ибо он переопределил поведение...
KP
Ожидается, что код поделен на слои.
И сообщения вылезают на последней стадии - рендеринг.
При четком делении слоев бизнеслогики и рендеринга нет описанных тобой проблем.
И сообщения вылезают на последней стадии - рендеринг.
При четком делении слоев бизнеслогики и рендеринга нет описанных тобой проблем.
DM
если у тебя один контроллер, одна модель и одна вьюха - конечно нет ;)
DM
а если запрос обрабатывает и собирает десяток сервисов... ну ну ;)
KP
а потом окажется, что один компонент выводит совершенно валидное сообщение, но есть второй компонент, который тоже выводит сообщение, но должен убрать сообщение первого, ибо он переопределил поведение...
По хорошему должны отработать оба компонента и потом уже когда известен результат кидается сообщение в стэк.
DM
А не можешь, у тебя уже комопненты кидают сообщения... менять компоненты ты не можешь, ибо одна из них или обе - используются в других местах и там это сообщение нужно
KP
В момент обработки запроса работает 1 контроллер, а точнее конкретный экшн.
Моделей может быть много, но вызываешь их из конкретного экшена конкретного контроллера. И уже потом отдаешь все на рендеринг.
Моделей может быть много, но вызываешь их из конкретного экшена конкретного контроллера. И уже потом отдаешь все на рендеринг.
KP
нет проблем
DM
Короче, так или иначе - сообщения должны собиратся в точке выхода... и не через сессии, а через состояния моделей / сервисов... а если у тебя все собирается в одной точке, то нахрена флеш, если дальше ты все-равно пойдешь на рендер...
KP
А не можешь, у тебя уже комопненты кидают сообщения... менять компоненты ты не можешь, ибо одна из них или обе - используются в других местах и там это сообщение нужно
Значит в контроллере проверяй результат отработки модели и выводи сообщение.
DM
о том и речь
DM
флеш сообщения в общем сделаны в основном для того, что бы толстые ответы тягать между двумя запросами
KP
Можно и так...
DM
что в общем тоже решается в большинстве случаев
DM
а как только начинается две ноды у тебя, тут то и приходить полярный зверь, ибо эти флеш сессии начинают жрать дорогую память, а не дешевый диск