SmartGWT GWT 客户端服务器架构
我们计划使用智能GWT，GWT和相关框架用于客户端丰富的接口，以及在服务器端返回JSON数据的Spring MVC。
作为调查它是否符合我们的要求的一部分，以下问题需要一些答案：
- 在不使用任何框架的情况下从头开始构建 GWT 应用程序将需要付出相当大的努力来遵循标准 MVP 模式。但这更灵活且可进行单元测试，尽管很耗时。 GWT 最佳实践建议使用 MVP 设计模式来构建更大的应用程序。
SmartGWT 有自己的方法，您可以使用一个小部件，向其中引入一个数据源，然后就完成了。尚未确定以模块化（或 MVP）方式构建此类智能 GWT 组件的最佳实践。任何建议
使用框架 GWT-platform 和 SmartGWT 可以是尝试此处提到的 MVP 架构的选项。有什么建议吗？
智能 GWT 的验证/消息/异常显示和其他通用功能支持还有待研究。
客户端服务器架构：在服务器端使用 Spring MVC + Spring 核心，在客户端使用 GWT + Smart GWT 可能是一个很好的开源技术堆栈，但考虑到 GWT 默认使用 RPC 进行客户端服务器交互，因此使用其中需要更好地评估。 （特别是身份验证/会话处理/安全等）。有什么建议吗？
谢谢
We plan to use smart GWT, GWT and related frameworks for the client side rich interface and Spring MVC which returns JSON data on the server side.
As part of the investigation to see if it fits our requirement, the following questions need some answers :
- Building a GWT application from scratch without using any frameworks will need considerable amount of effort to follow the standard MVP pattern. But this is more flexible and unit testable, though time consuming. GWT best practise suggests using MVP design pattern for building larger applications.
SmartGWT has its own approach, where you use a widget, introduce a datasource into it and you are done. Yet to identify the best practise around building such smart GWT components in a modularised (or MVP) fashion. Any suggestions
Using framework GWT-platform and SmartGWT could be an option to try MVP architecture as mentioned here. Any suggestions?
Validation/message/exceptions display and other generic feature support of smart GWT is yet to be investigated.
Client server architecture: Having Spring MVC + Spring core on the server side and GWT + Smart GWT on the client side could be a good stack of open source technologies, but given that GWT by default uses RPC for client server interaction, usage of these needs to be better evaluated. (esp. authentication/session handling/security etc). Any suggestions?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我从来没有使用过 SmartGWT 或任何其他丰富的库。我的观点可能有偏见，但我确实认为 Gwt 组件易于定制且轻量级。这是我从 SmartGwt 中从未感受到的东西，是任何其他类型的库的。
话虽这么说，以下是我对您关心的两个问题的回答：
好吧，要在这方面保持 MVP，只需从演示者设置数据源即可。在您看来，SmartGWT 小部件应该是“被动”的，并等待来自演示者的配置。
优点：您不必对视图进行单元测试，因为 SmartGWT 小部件应该已经经过了良好的测试。您只需在实际调用视图的地方测试演示者即可配置该小部件并验证是否正确调用它。
RPC 是一个选项，而不是默认通信。还有两种其他类型的通信（如果您尝试 DeRPC 等实验性功能，甚至更多）：RequestBuilder 和 RequestFactory。
RequestBuilder 可用于带有 JSON 响应的 HTTP GET。无法帮助您实现智能 GWT 方法。
这是一位使用Smart GWT的Gwt-Platform用户，阅读他的博客，应该会对您有所启发：
http://uptick.com.au/blog
在撰写此答案时，博客已关闭，但应该很快就会回来。
I nerver used SmartGWT or any other rich libraries. My opinions may be biased, but I really think that Gwt components are easy to customize and lightweight. That's something I never felt coming from SmartGwt are any other librairie of that type.
That being said, here's my answer to two of your concern:
Well, to stay MVP like in that aspect, just set the datasource from the presenter. In your view, the SmartGWT widget should be "passive" and wait for configuration coming from the presenter.
Advantage: You don't have to unit test the view, since SmartGWT widgets should already be well tested. You only have to test the presenter where you actually call the view to configure that widget and verify if you call it correctly.
RPC is an option, not the default communication. There's two other type of communication (and even more if you try experimental feature like DeRPC): RequestBuilder and RequestFactory.
RequestBuilder could be use to HTTP GET with JSON Response. Can't help you for the smart GWT approach.
Here's a user of Gwt-Platform that use Smart GWT, read his blog, it should enlighten you:
http://uptick.com.au/blog
At the time of writing this answer, the blog was down, but it should come back soon.
我目前正在开发 Smart GWT / GWT 应用程序。
目前我对Smart GWT的看法是，它确实节省了很多时间，而且它提供了一些好看、有用的小部件。也就是说，因为它是 JavaScript 库的包装器，所以它确实有一些警告，特别是在调试时。通常，与使用普通 GWT（或带有非 JavaScript 包装器的库的 GWT）相比，跟踪错误要困难得多。
尝试对您的问题发表评论：
我还没有发现 Smart GWT 库在这方面存在问题。它可能与 GWT 推荐的方式不同，但这并不意味着您必须突然放弃所有最佳实践。
对此无法真正发表评论 - 尚未发现验证/消息/异常库是一个问题
我们使用 JAX-RS 进行客户端/服务器通信，Smart GWT 本身支持并且非常容易实现。它可能比 GWT RPC 更容易调试，因为它使用 XML 格式。我们只是使用 Spring Security 来保证安全性，而且没有任何问题。
我认为对我们来说，让我三思而行再次使用 Smart GWT 的主要问题是可定制性：例如，当您使用它们的表单时，您无法在布局方面对它们做太多事情。 Smart GWT 有它自己的做事方式，除非您想编写自己的组件，否则您几乎只能采用这种方式（这并不理想，因为 Smart GWT 不建议混合使用 Smart GWT 和普通 GWT 组件）。
如果您乐意编写一个使用 Smart GWT 库并且不需要太多自定义的应用程序，那就没问题了。
I am currently working on a Smart GWT / GWT application.
My opinion of Smart GWT currently is that it does save a lot of time, and it provides some good-looking, useful widgets. That said, because it's a wrapper around a JavaScript library it does have some caveats, particularly when debugging. Often it makes it much more difficult to track down an error than it would be using plain GWT (or GWT with a library that wasn't a JavaScript wrapper).
To try and comment on your questions:
I haven't found the Smart GWT libraries to be a problem in this respect. It's probably different to the GWT recommended way but it doesn't mean you suddenly have to abandon all best practices.
Can't really comment on this - haven't found the validation / message / exception libraries to be an issue
We use JAX-RS for the client / server communication, which Smart GWT supports natively and is pretty easy to implement. It's possibly a bit easier to debug than GWT RPC because it uses an XML format. We just use Spring Security for the security and, again, no issues there.
I think the main thing for us that would make me think twice about using Smart GWT again is the customisability: when you use their forms, for example, you can't do very much with them in terms of layout. Smart GWT has its own way of doing things, and you're pretty much locked into that way unless you want to write your own components (which isn't ideal because Smart GWT don't recommend mixing Smart GWT and plain GWT components).
If you're happy to write an application which uses the Smart GWT library and doesn't require much customisation it would be fine.
您应该首先考虑使用 MVP 的目标。
如果您查看 SmartGWT 示例，您会发现它们已经具有清晰且最少的代码。您无法通过引入 MVP 来简化或澄清任何示例，只能添加额外的代码和复杂性。
因此，您应该有一个非常具体、具体、非常令人信服的理由来解释为什么要使用 MVP 并引入额外的代码：一个特定的设计目标，无法通过正常使用 SmartGWT 以更简单的方式实现。
很难找到这种有效的目标，因为 SmartGWT 非常灵活并且已经支持通过 Selenium 进行测试，甚至还具有 Selenium IDE 扩展和对 Selenium RC 的支持。
追求 MVP 的合理理由的一个可能示例可能是拥有两个完全独立的视图实现，一个在 SmartGWT 中，另一个在普通 GWT 中简化。我知道，这不是一个很好的例子，很难想象有人需要这样做，但那是因为除了非常模糊的灵活性概念之外，我们还没有任何开发人员出现并阐明将 MVP 与 SmartGWT 结合使用的原因。
如果你要承担使用 MVP 的任务，我认为你应该充分了解情况，可以说“我们需要做 X，如果我们正常使用 SmartGWT，这将需要 6 个月，如果我们添加 MVP，需要3英寸。据我所知，没有人发现过这样的场景。
You should first consider your goals in using MVP.
If you look over the SmartGWT samples, you'll find they already have clear and minimal code. You can't simplify or clarify any of the samples by introducing MVP, you can only add additional code and complexity.
So you should have a very specific and concrete, very compelling reason why you want to use MVP and introduce extra code: a particular design goal that cannot be met in a simpler way by using SmartGWT normally.
It's very hard to find a valid goal of this kind, because SmartGWT is very flexible and already supports testing via Selenium, and even has Selenium IDE extensions and support for Selenium RC.
A possible example of a valid reason to pursue MVP might be having two completely separate view implementations, one in SmartGWT and a simplified one in plain GWT. I know, it's not a very good example and it's hard to imagine anyone needing to do this, but that's because we have yet to have any developer come along and articulate a reason to use MVP with SmartGWT other than very vague notions of flexibility.
If you're going to take on the task of using MVP I think you should understand the situation well enough to say something like "we need to do X, and if we use SmartGWT normally that will take 6 months, if we add MVP, it will take 3". To my knowledge, no one has ever identified such a scenario.