GWT 多对话框应用程序架构和 MVP/活动/地点
这里对 GWT 活动/位置/MVP 概念进行了很多讨论，但我还没有找到如何将这些概念应用到类似多对话框门户的 GWT 应用程序的好示例。
我正在开发一个应该有多个独立小部件的 GWT 应用程序。这些小部件是基于 弹出面板。每个小部件都可以在屏幕上移动，并且应该独立于其他小部件。最初的目的是使用“活动和场所”方法。每个小部件都是一个活动，所有活动都由相同的 ActivityMapper 和 ActivityManager 管理。但在这种情况下，每当从菜单中打开新对话框时，都会创建新的 Place 并为当前打开的对话框调用 mayStop() 。每种小部件类型都有一个 ActivityMapper 和 ActivityManager 也是行不通的，因为屏幕上可能有多个相同类型的小部件。
在这种情况下，GWT 应用程序的架构应该是什么样子？有什么建议吗？
GWT Activities/Places/MVP concepts were discussed quite a lot here, but I haven't found a good example of how to apply those concepts to a multi dialog portal-like GWT application.
I'm working on a GWT application that should have multiple independent widgets. These widgets are implemented based on PopupPanel. Each widget can be moved around on the screen and should be independent of others. The original intention was to use Activities and Places approach. Each widget would be an activity, all activities would be managed by the same ActivityMapper and ActivityManager. But in that case whenever new dialog is opened from the menu, new Place is created and mayStop() is called for the currently opened dialog. Having one ActivityMapper and ActivityManager per widget type is not going to work either since there could be several widgets of the same type on the screen.
How should architecture of a GWT application look like in this case? Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
地点就像 URL，它似乎不符合您的需求，除非您构建一个包含所有小部件的累积状态的超级地点。
每个“小部件”绝对需要一个 ActivityMapper 和 ActivityManager （或者完全不使用活动）
A place is like a URL, it doesn't seem to fit your needs, unless you build a super-place containing the accumulated state for all widgets.
You absolutely need an ActivityMapper and ActivityManager per "widget" (or not use activities altogether)