GWT: Детализация Places и ActivityMappers

Я наконец начинаю "получать" GWT. В любой момент PlaceChangeEvent можно запустить в приложении EventBus следующим образом:

History.newItem("token-for-some-new-place");

Это добавляет событие в шину, в результате чего зарегистрированный ActivityManager получает его и консультируется со своим внутренним ActivityMapper, чтобы передать ему Activity, связанный с Place PlaceChangeEvent.

Затем Activity (аналогично объекту презентатора или контроллера из MVP/MVC) получает любые необходимые данные (посредством вызовов RPC к серверу), выполняет любую бизнес-логику и настраивает окончательное представление (обычно Composite какого-либо вида) для отображения. .

Пока мы говорим о сверхпростом приложении GWT, которое имеет только одну область отображения на главной странице, то, как я уже сказал, я «понимаю».

Теперь я задыхаюсь, когда у вас есть приложение, содержащее несколько областей отображения (области, которые могут обновляться асинхронно друг от друга).

Поэтому я спрашиваю:

  1. Насколько детализированными должны быть ActivityMapper? Существует ли только один AppActivityMapper для всего приложения, который сопоставляет все Place со всеми Activity, или должна быть какая-то ActivityMapper иерархия/декомпозиция, где у вас есть несколько сопоставителей? (И если ваш ответ на это что-то вроде «это зависит от потребностей вашего приложения», то, пожалуйста, объясните, какие требования/потребности определяют соответствующий уровень детализации!)
  2. Если Place представляет токен URL в вашем приложении (для того, чтобы сделать Place состояние закладкой), то что произойдет, если у вас есть более сложное приложение с несколькими областями отображения (D1, D2, D3). Как один токен URL (например, http://myapp.com/#token-for-some-new-place) сопоставляется с D1, D2 и D3? Разве это не означает, что ActivityMapper#getActivity должна быть способна возвращать список действий (List<Activity>), чьи start(AcceptsOneWidget, EventBus) методы будут вызываться?

Спасибо за любую помощь здесь - примеры кода всегда потрясающие.


java mvp gwt gwt-activities gwt-places
person Community    schedule 27.10.2012    source источник
comment
Если вы используете места, я бы посоветовал вам использовать только места (PlaceController.goTo()), а не низкоуровневые History.   -  person Thomas Broyer    schedule 28.10.2012
comment
Спасибо, Томас, но это ответ на вопрос, который я не задавал.   -  person    schedule 28.10.2012
comment
И поэтому я добавляю это как комментарий ;-)   -  person Thomas Broyer    schedule 28.10.2012

Ответы (1)


arrow_upward
5
arrow_downward

Place представляет, ну, место. Он отвечает на экзистенциальные вопросы откуда я взялся?, где я сейчас? и куда я иду?.

Для определенного места экран, отображаемый пользователю, может быть сложным и разделенным на несколько областей отображения. Каждое из них управляется ActivityManager, который спрашивает ActivityMapper, какое Activity использовать для данного места, что делает все слабо связанным (действия не (должны) знать, где они используются, для какого места, какие другие действия работают одновременно и т.д.)

Таким образом, у вас будет не маппер, возвращающий список действий, а список мапперов, каждый из которых возвращает одно действие.

Видеть:

person Thomas Broyer    schedule 27.10.2012
comment
Спасибо @Thomas Broyer (+1) - однако здесь вы говорите, что Place существует на уровне страницы/экрана, тогда как ActivityManagers и ActivityMappers существуют на уровне области отображения (где экран состоит из 1+ показать регионы). Но как это возможно? Если области отображения D1, D2 и D3 могут существовать в 5 доступных для закладки состояниях, и все они принадлежат одному и тому же экрану, то экран может существовать в 5^3 = 125 доступных закладках. состояния! Как одно (на уровне экрана) место может представлять 125 штатов! - person ; 28.10.2012
comment
Не уверен, что понимаю, о чем вы говорите, но мой предварительный ответ будет таким: все области отображения изменяются одновременно (это не означает, что они должны меняться, вы можете иметь некоторые из они отображают ту же активность, что и для другого места, но все же их попросили отобразить активность для текущего места). Здесь, в StackOverflow, строка меню (с логотипом), раздел с тегами в правом верхнем углу, бюллетень сообщества, реклама и все, что ниже, и, наконец, основная область с вопросами и ответами; 1 URL (место) определяет, что отображается в каждой области (действия). - person Thomas Broyer; 29.10.2012
comment
Аааа... так что, используя мой пример выше, если регионы отображения D1, D2 и D3 могут существовать в 5 состояниях, доступных для закладок, то, учитывая URL-адрес, скажем, http://myapp.com/#some-state, у каждого из них будут свои собственные независимые преобразователи, которые знают, что Activity показывать. Это имеет смысл, спасибо! - person ; 29.10.2012