Пытаюсь "раскурить" шаблон проектирования MVP(сам занимаюсь backend'ом обычно).
Возник вопрос касательно роли presenter'а во всем этом деле.
Итак пример:
Есть вид master-detail. Master — дерево. Detail — редактор.
В зависимости от выбранного элемента дерева(2 типа), в detail нужно показывать разные редакторы этих элементов.
Допустим мышью выделили элемент в дереве, сообщили об этом presenter'у, тот в свою очередь загружает информацию по этому
элементу и дальше.....кто должен менять содержимое detail? Сам вид или же его presenter?
Более общий вопрос: чем должен заниматься presenter?
Здравствуйте, kokaku, Вы писали:
K>Добрый вечер!
K>Пытаюсь "раскурить" шаблон проектирования MVP(сам занимаюсь backend'ом обычно). K>Возник вопрос касательно роли presenter'а во всем этом деле.
K>Итак пример: K>Есть вид master-detail. Master — дерево. Detail — редактор. K>В зависимости от выбранного элемента дерева(2 типа), в detail нужно показывать разные редакторы этих элементов. K>Допустим мышью выделили элемент в дереве, сообщили об этом presenter'у, тот в свою очередь загружает информацию по этому K>элементу и дальше.....кто должен менять содержимое detail? Сам вид или же его presenter?
K>Более общий вопрос: чем должен заниматься presenter?
K>Спасибо
По идее prsenter, а view должна предоставить презентору интерфейс для этого. Хотя иногда проще оставлять часть презентативной логике в view, к тому же она все равно там есть, ведь элементы tree выделяются без помощи презентера.
Здравствуйте, Qulac, Вы писали:
Q>По идее prsenter, а view должна предоставить презентору интерфейс для этого.
А что из себя должен представлять это интерфейс: тупо куча get'теров на компоненты вида(Tree, Button, TextField,...) или что-нибудь более высокоуровневое типа: включи свое состояние в режим редактирования элементов типа №1(activateEditor1()) или типа №2, а дальше вид сам уже "решит" что в каком состоянии прятать, показывать, "дисаблидь", "енаблить"? Или же 2ой вариант сильно крут для "тонкого вида" — уж много он знает получается, нет?
Здравствуйте, kokaku, Вы писали:
K>Здравствуйте, Qulac, Вы писали:
Q>>По идее prsenter, а view должна предоставить презентору интерфейс для этого.
K>А что из себя должен представлять это интерфейс: тупо куча get'теров на компоненты вида(Tree, Button, TextField,...) или что-нибудь более высокоуровневое типа: включи свое состояние в режим редактирования элементов типа №1(activateEditor1()) или типа №2, а дальше вид сам уже "решит" что в каком состоянии прятать, показывать, "дисаблидь", "енаблить"? Или же 2ой вариант сильно крут для "тонкого вида" — уж много он знает получается, нет?
А это по обстоятельствам. Например: пользователь ввел в диалоговом окно данные, теперь их нужно отобразить в гриде. Добавляем такой метод к вью:
Здравствуйте, kokaku, Вы писали:
K>А что из себя должен представлять это интерфейс
Этот интерфейс должен быть таким, чтобы легко можно было заменить эту View на другую. Ведь это основное преимущество MVP — возможность нескольких View. Берешь интерфейс, реализуешь его — и у тебя ещё один вариант отображения
Здравствуйте, xednay89, Вы писали:
X>Здравствуйте, kokaku, Вы писали:
K>>А что из себя должен представлять это интерфейс
X>Этот интерфейс должен быть таким, чтобы легко можно было заменить эту View на другую. Ведь это основное преимущество MVP — возможность нескольких View. Берешь интерфейс, реализуешь его — и у тебя ещё один вариант отображения
те самый "идеальный" интерфейс, который возвращает компоненты вида?
Или все же нет?
Здравствуйте, kokaku, Вы писали:
K>те самый "идеальный" интерфейс, который возвращает компоненты вида?
Непонятно, как это следует из моего сообщения. И смотря что вы подразумеваете под "компонентами вида".
Как вытаскивание наружу "компонентов вида" облегчит создание новых view? Например вы выставили зависимость на какой-то ViewComponent. Теперь вы сможете создать View только на тех технологиях и библиотеках, которые вообще имеют этот компонент.