Добрый вечер!

Пытаюсь "раскурить" шаблон проектирования 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ой вариант сильно крут для "тонкого вида" — уж много он знает получается, нет?

А это по обстоятельствам. Например: пользователь ввел в диалоговом окно данные, теперь их нужно отобразить в гриде. Добавляем такой метод к вью:

 void AddObjctView(//данные из диалоговой формы);

Здравствуйте, kokaku, Вы писали:

K>А что из себя должен представлять это интерфейс

Этот интерфейс должен быть таким, чтобы легко можно было заменить эту View на другую. Ведь это основное преимущество MVP — возможность нескольких View. Берешь интерфейс, реализуешь его — и у тебя ещё один вариант отображения

Здравствуйте, xednay89, Вы писали:

X>Здравствуйте, kokaku, Вы писали:

K>>А что из себя должен представлять это интерфейс

X>Этот интерфейс должен быть таким, чтобы легко можно было заменить эту View на другую. Ведь это основное преимущество MVP — возможность нескольких View. Берешь интерфейс, реализуешь его — и у тебя ещё один вариант отображения

те самый "идеальный" интерфейс, который возвращает компоненты вида?
Или все же нет?

Здравствуйте, kokaku, Вы писали:

K>те самый "идеальный" интерфейс, который возвращает компоненты вида?

Непонятно, как это следует из моего сообщения. И смотря что вы подразумеваете под "компонентами вида".
Как вытаскивание наружу "компонентов вида" облегчит создание новых view? Например вы выставили зависимость на какой-то ViewComponent. Теперь вы сможете создать View только на тех технологиях и библиотеках, которые вообще имеют этот компонент.