Модель в GWTP - поднятие изменившихся событий - PullRequest
1 голос
/ 20 марта 2012

Мы разрабатываем новое приложение с использованием GWTP (GWT 2.4).

Существует довольно много статей, касающихся дизайна представления докладчика - обязанности каждого компонента, связь между ними - но меньше вниманияпредоставляется компоненту модели.

В нашем приложении мы используем Действия GWTP и получаем от сервера некоторое DTO, на котором мы в основном выполняем CRUD.У нас есть некоторая оболочка UI-Entity каждого DTO.Этот UI-объект содержит все необходимые метаданные для просмотра (какие свойства он имеет, их отображаемое имя и т. Д.) И предоставляет set / get для всех свойств.

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

  1. UI-Entity вызывает события.
  2. Действие вызывает события при обратном вызове с сервера.

Я думаю, что большая разница между этими двумя методами заключается в том, что первый вариант делает модель «живой» - если пользователь вносит изменения, они отражаются в приложении, даже если они не отправляются на сервер.Во втором варианте приложение будет знать о событиях изменения данных только тогда, когда данные действительно были изменены на сервере.

На мой взгляд, обычно вам нужны оба подхода, но я не могу найти примеры, поддерживающие первый подход:обычно, когда рассматривается первый подход - он утверждает, что это скорее дизайн MVC, чем MVP.

Что вы думаете?Любые рекомендации?

Бен

1 Ответ

0 голосов
/ 05 июля 2012

В первом случае вы должны иметь возможность использовать propertychangeevent с зарегистрированными слушателями, обычно, если у вас есть текстовое поле, в этом поле будет прослушиватель изменения свойства, а затем всякий раз, когда поле изменяется, некоторые событие будет запущено в автобус. Естественно, вам все еще нужно привязать пользовательский интерфейс к объекту модели (я предлагаю Gwittir, он делает все это очень хорошо).

Вторая проблема аналогична: сервер выполняет обратный вызов через любые средства, которые у вас есть, и затем это должно вызвать событие на шине, которое говорит: «поле, что имеет новое значение !!!», и в этот момент отдельные поля (которые должны быть зарегистрированы и прослушиваются) могут решать, следует ли прослушивать это событие и реагировать соответствующим образом.

Таким образом, в основном ваши поля должны прослушивать шину, и всякий раз, когда модель изменяется, со стороны сервера или пользовательского интерфейса, на шину должно отправляться сообщение, чтобы любые заинтересованные слушатели могли обработать это изменение. Это разъединяет дизайн и обрабатывает оба случая. И упрощает сложные взаимодействия на уровне виджетов.

Я не думаю, что эта установка нарушает MVP каким-либо значимым образом, чтобы быть самым чистым (когда я создаю MVP), вы могли бы попросить вашего докладчика прослушать шину, а затем сказать, что представление меняется, но мне кажется, что бессмысленный уровень абстракции, связи и источника ошибок и дальнейшей работы позже.

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

...