GWT, MVP и UIBinding - Как получить лучший из всех миров

С MVP Вы обычно связываете Представление (UI) с Предъявителем в Предъявителе. Однако с последней версией GWT, особенно с UIBinding, можно сделать следующее в Представлении:

@UiHandler("loginButton")
void onAboutClicked(ClickEvent event) 
{
    // my login code
}

Который в основном обменивается большим количеством анонимного внутреннего кода класса для некоторого быстрого кода аннотации.Очень мило!! Проблема состоит в том, что этот код находится в представлении а не предъявителе...

Таким образом, я думал, возможно:

@UiHandler("loginButton")
void onAboutClicked(ClickEvent event) 
{
    myPresenter.onAboutClicked(...);
}

Но существует несколько проблем с этим подходом. Самое важное, Вы стираете грани между Представлением и Предъявителем. Кто делает, который, связывая, в некоторых случаях это - Представление, в других это - предъявитель (связывающий с событиями не в Вашем текущем представлении, но который должен быть присоединен - например, событие обновления в масштабе всей системы).

Вы все еще извлекаете пользу из способности к модульному тесту Ваш предъявитель, но в том, что стоит. Обязанности грязны теперь. Например, привязка иногда находится в Представлении и времена других на уровне Предъявителя. Я вижу, что код попадает во все виды хаоса со временем.

Я также думал о расширении Предъявителя к Представлению, так, чтобы Вы могли сделать это в Представлении. Проблема здесь состоит в том, что Вы теряете способность Предъявителя выполнить стандартные модульные тесты! Это - главная проблема. Это и строки снова становятся размытыми.

Так мой вопрос, у кого-либо есть хороший метод использования в своих интересах аннотации от UIBinding в шаблоне MVP, не стирая грани и теряя преимущества шаблона MVP?

9
задан Stephane Grenier 15 March 2010 в 16:43
поделиться

3 ответа

Если честно, я не используйте аннотацию @UiHandler , потому что, как вы сказали, она начинает размывать границы между View и Presenter. Это совершенно нормально в использовании и отличный ярлык, если вы не особо заботитесь о том, чтобы придерживаться шаблона.

Маршрут presenter.onAboutClicked () определенно является вариантом, но тогда вы могли бы также определить обработчик в презентаторе в первую очередь.

4
ответ дан 4 December 2019 в 14:28
поделиться

Я предпочитаю использовать подход @UiHandler только тогда, когда Обработчик выполняет специфичные для представления вещи, такие как добавление имен стилей и т. Д. Для других целей (добавление проверки и т. д.) я придерживаюсь старого подхода, добавляя соответствующие обработчики в Presenter.
Я бы порекомендовал прочитать одну из многих тем в группе Google GWT о MVP и UiBinder, например этот .

9
ответ дан 4 December 2019 в 14:28
поделиться

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

gwt 2.0.x является большим улучшением по сравнению с gwt 1.x, но я все еще считаю, что у Google есть какой-то путь к их документации и руководству, поскольку, как мы видели с uibinder и mvp, это оставляет много для воображения о том, как заставить вещи работать.

надеюсь, что ссылка оттенит немного больше света на то, что вам нужно.

1
ответ дан 4 December 2019 в 14:28
поделиться