T
Я уже объяснил один серьезный минус. И точечные презентеры помогут его избегать.
Size: a a a
2021 April 23
AB
если у тебя есть вопрос версионирования схем в api - это в общем не очень зависимая от content negotiation тема
T
При этом давая все то, что ты перечислил
LL
Презентеры имеют место, я вообще не против них, опять же. Если ты уверен что твоё апи предоставляет ресурсы-объекты и один вид представления данных (например, всегда последнюю версию), то пожалуйста.
Вью просто решают другие проблемы
Вью просто решают другие проблемы
AB
в вики вообще какая-то дичь дикая нарисована
AB
точнее, не дичь, ок, но вообще не то, о чем мы сейчас говорим Х)
T
Две версии - два разных презентера под разные версии. Я не вижу, зачем здесь View модуль. Неужели тут никого не смущает, что он обязательный в фениксе и в поголовном большинстве случаев просто пустой?
T
Это бойлерплейт
ŹR
Что такое презентер?
DR
А какое отношение dashbit имеет к phoenix-у? Там же больше другой, как его имя, дизайнил phoenix
T
Поставщик данных для вьюхи
ŹR
Крыс Аккорд
AM
к черту нюансы мы тут феникс хуесосим!
ŹR
А что такое вьюха?
ŹR
Презентер же вместо контроллера , не?
ŹR
А вы пытаетесь захуесосить вьюхи
ŹR
Хотя они и в mvp и в mvc
LL
Да, феникс в этом плане избыточный, это нормально, это фрейворк. Если тебе не нужен
Но ты тут, по-моему, путаешь вью и презентер. Презентор это то, что предоставляет логику поверх вьюхи. Поэтому в случае с версиями, у тебя был бы один презентер, который принимал бы аргумент
mvc, то используй плагНо ты тут, по-моему, путаешь вью и презентер. Презентор это то, что предоставляет логику поверх вьюхи. Поэтому в случае с версиями, у тебя был бы один презентер, который принимал бы аргумент
version и в зависимости от него бы рисовал данныеŹR
Так что я не понимаю
LL
Вот именно