Подтвердить что ты не робот

Vaadin 7: Использование UI против Navigator + Views

В Vaadin 7 веб-приложение может иметь несколько точек входа; пользовательские интерфейсы. Каждый UI может иметь только один Navigator содержащий View s.

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

В чем преимущества и неудобства UI и Navigator? Существуют ли какие-либо рекомендации по этому выбору?

4b9b3361

Ответ 1

Я рекомендую использовать один пользовательский интерфейс с Navigator, поскольку, на мой взгляд, это достаточно, чтобы выполнить эту работу. Главным неудобством многих пользовательских интерфейсов является перезагрузка при переключении между ними. Также вам нужно будет помнить о желаемой согласованности, например. иметь одинаковый заголовок в каждом пользовательском интерфейсе. И по моему опыту вы наверняка встретите больше проблем; -)

Чтобы сделать его чистым, вы должны использовать MVP patter. Я использую аналогично этому с com.google.common.eventbus.EventBus для обработки событий. Я добавляю eventBus к своим представлениям, размещаю события там и обрабатываю их в соответствующем ведущем, не внедряя слушателей, которые, на мой взгляд, более проблематичны. Поскольку MVP уже резервирует "презентатор" и "просмотр", я называю страницу Vaadin "страница".

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

Navigator n = new Navigator(UI.getCurrent(), layout);

Для управления навигацией я создал PagesEnum, и при смене вида я публикую ChangePageEvent, который получает параметр PageEnum.SOME_PAGE в качестве параметра. Опционально также имеется идентификатор элемента для отображения. Поэтому в MainPresenter у меня есть:

@Subscribe
public void changePage(ChangePageEvent event) {
    String url = event.getPageName();
    if (event.hasId()) {
        url += "/" + event.getEntityId();
    }
    navigator.navigateTo(url);
}

Тогда есть разные возможности:

  • в режиме ввода страницы (вид Vaadin) убедитесь, что отображается соответствующее подменю.

  • добавьте его как параметр в ChangePageEvent и обработайте его в методе changePage.

  • hardcode это в PageEnum как новое поле, например. subMenu и создать другое перечисление для подменю, поменять его в методе changePage.

Подменю будет, вероятно, за пределами контейнера, с которым вы подключаете Navigator, поэтому вы можете создавать SubMenuPresenter и SubMenuView для изменения подменю.

Ответ 2

Тема вашего вопроса заставила меня потеть очень в прошлом 2013 году. Я изучал, анализировал и тестировал различные аспекты пользовательских интерфейсов и навигатора Vaadin 7.

Я посмотрел большое количество фреймворков, вики и бумаги на эту тему; связанных и не связанных с Ваадином 7.

Это было некоторое время назад (в начале 2013 года), я не новичок в этом вопросе; в любом случае это некоторые из ссылок, которые я могу воскресить:

Наши требования были несколько похожи на сценарий Vaadin MVP Lite; но нам нужно было больше абстракции и гибкости в отношении состава представлений. Я старался использовать предоставленный Navigator, но это было легко настроить.

Навигатор - это конкретный класс. В пользовательских интерфейсах может быть только один навигатор. В конструкторе Navigator вы можете найти эту строку:

this.ui.setNavigator(this);

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

Затем я нашел это руководство, которое поставило меня на интересную дорогу: Составление пользовательского интерфейса, глава 7 - MicrosoftDN Microsoft

Статья действительно приятна и освещена; хотя он имеет много общего с тем, как работает Delphi или какой-либо другой компонентный подход, концепция "Region" была действительно благословением. Другие главы действительно интересны (модульная разработка приложений и MVVP).

В итоге мы приняли концепцию Region только с одним пользовательским интерфейсом. Вкратце он работает следующим образом:

  • Существует компонент GUI, который может размещать другие компоненты; Места, где он может размещать другие компоненты, похожи на "дыры". Каждое отверстие зарегистрировано, и это регион, связанный с именем строки (простой hasmap).
  • По имени Region можно "поместить" другой компонент Vaadin в Регион, чтобы сделать его видимым.

Что происходит, когда пользовательский интерфейс включен, так это то, что один регион зарегистрирован (весь пользовательский интерфейс) в качестве "корневого" региона. Затем компонент, который представляет форму входа, размещается в области "root". Если выполнена успешная попытка входа в систему, другой компонент размещается в области "root" (удаление компонента входа); этот самый компонент также является хостом: он регистрирует другой регион под названием "main" и имеет меню навигации в левой части экрана. Теперь, если вы хотите отобразить компонент (например, страница приветствия), вы можете получить "основной" регион и отобразить компонент.

Vaadin Navigator реализует поддержку закладки и обратной кнопки. Мне было грустно, потому что мы не развивали его, но это не было требованием для нашего приложения. ИМХО, ребята из Ваадина сделали жесткое, но хорошее решение, оставив Navigator простым; управление государством нелегко реализовать. Было бы неплохо, если бы в будущем Navigator был более расширяемым. В любом случае, я думаю, что текущий Navigator отвечает самым средним потребностям.

Мой ответ длиннее, чем предполагалось; Надеюсь, мои усилия помогут.