GWT MVP 导航侧边栏

Question

我正在使用GWT编写网络应用程序，遵循GWT网站上的MVP教程（即使用{{link2：History}}导航）。

我有些困惑如何最好地拥有一个侧边栏进行导航（即单击导航链接更改主窗口中的内容。见下文）。

--------------------
|     |            |
| nav |   main     |
|     |    window  |
|     |            |
|     |            |
--------------------

我认为一种可能的做法是在HTML中声明两个<div>标签，用于导航和内容。例如：

@Override
public void onValueChange(ValueChangeEvent<String> event) {

    ...

    if (token.equals("navigation")) {
        presenter = new NavigationPresenter(rpcService, eventBus, new NavigationView());
        presenter.go(RootPanel.get("navigation"));
    }

    ...

    if (token.equals("content")) {
        presenter = new ContentPresenter(rpcService, eventBus, new ContentView());
        presenter.go(RootPanel.get("content"));
    }

    ...
}

我不确定这是否是最佳方法。 （我猜导航面板和内容窗口之间的双向通信可以通过“EventBus”来完成？当涉及更改UI时，这种方法是否灵活（例如用于移动站点）？）

我想知道人们建议采取什么最佳方式。我已经阅读了很多讨论Activities and Places，但据我所知，它们与MVP架构有些不同（activities and places对于browser history management非常有用，尽管我认为我的History的使用涵盖了它（？））。

任何建议将不胜感激。

- ChrisSSocha

Answer 1

是的，你是对的：Activies and Places与历史和导航管理有关，是GWT框架内的一个框架。 MVP仅是一种架构设计模式。您可以使用如您链接的文章中所示的框架来实现MVP。

在您的示例中，您可以按照您的说法执行操作，但我会使每个视图成为（延迟）单例，以避免任何可能昂贵的重新创建。就我个人而言，我不喜欢这种方式，因为最终您将以（如此多的）HasXxx接口来定义Display。

我认为如果历史管理很重要，选择Activities and Places几乎是不言自明的（至少对我来说，至少是为了定义应用程序的框架）。在这里您可以找到一个真正好的文章来帮助您入门。您将看到您的用例有多常见：必须定义显示区域（您的导航和主要区域），这些区域将根据位置更改反应（由于活动管理器），并创建/重新启动将依次更新UI的活动。这样，您就可以实现某种应用程序范围的MVP，其中演示者是活动。

就MVP而言，没有一种“最好的”方法： 第1部分，第2部分和MVP with A&P仅是实现相同目标的不同方法：演示和业务逻辑之间的分离，以及纯粹的Junit测试。只需选择您喜欢的内容。有关参考，请参见组中的此帖子。

希望这能让您入门。

- Andrea Boscolo

---

首先，@Andrea Boscolo 绝对是正确的：我已经从各个角度研究了历史管理，而 Activities & Places 是实现历史映射而不必重复造轮子的最佳方式。 - Michael Técourt

它唯一的缺点是 PlaceHistoryMapper 的 @WithTokenizers 生成令牌的方式：在我看来，URL 太丑了，地方前缀由“：”分隔，然后是参数。我已经实现了“自我令牌化”的位置，生成像这样的 URL：“www.myapp.com/#/placeprefix/param1=value1＆param2=value2”，而不是 GWT 的标准格式: www.myapp.com/#placeprefix:anythingelseinthetoken......这只是因为我可能是一个 URL 狂人。 - Michael Técourt

Answer 2

对于我的应用程序，我使用像GWT文档中一样的ClientFactory，并使用Views的单例。

这样，应用程序结构（包括菜单）也是在ClientFactory中引用的单例，因此每个其他视图都可以通过其接口直接访问它。

例如，某些视图可能会将某些图像推送到标题中，在隐藏菜单以显示视频或其他所需内容。大多数情况下，应用程序的结构不需要单独的活动/位置来“保留”其状态在历史堆栈中...

我知道大多数人不喜欢视图相互调用，我也是如此，唯一的例外是应用程序的结构视图，它有一个不是活动的Presenter，并且视图本身始终显示。

使用通知在您的应用程序结构和其他视图之间进行通信会使您的应用程序变成意大利面条式代码。我曾经使用过PureMVC等框架，这些框架非常依赖事件/通知来在视图之间进行通信，但是这种分离具有很高的代价：可维护性和代码可读性。

- Michael Técourt