8

Vaadin 网站上的 GWT 页面有点稀疏：https ://vaadin.com/gwt

“只有好处，没有陷阱您将享受 GWT 中您喜欢的一切，并获得新颖的服务器端编程模型、组件、工具、主题和其他附加功能的额外好处。如果您不喜欢您所看到的，这很容易只要你坚持使用 com.google.* 包，就会返回。你可能最终会想开始使用 com.vaadin.* 包中的功能。但不用担心——Vaadin 框架也在同一自由 Apache 2.0 许可证”

我喜欢 Vaadin 网站上的一些外观和感觉，但我对“服务器端模型”感到紧张......如果可能的话，我宁愿让大部分代码在客户端运行，我正在检查 GWT为安全起见，再次调用 RPC（通常使用相同的 java 代码）。我不喜欢很多来回的想法。

考虑到我的担忧，是否值得深入研究 Vaadin？还是我停在这里？我可以在不忍受所有东西的情况下利用各种外观和感觉吗？任何其他关于杠杆作用的非直观答案将不胜感激。

更新：请不要回答比较 Vaadin 与 GWT 的问题，提供替代 UI 框架。

我还使用过 SmartGWT、GXT 和捆绑的 GWT 小部件等。还熟悉一些非常完整的小部件集，例如 DevExpress for .NET。我问这个问题的原因是因为 Vaadin 看起来真的很酷......我正在寻找这样的答案：不，不可能在不损害客户端的情况下从 Vaadin 提取 L&F，或者除了 L&F 的东西之外，还有很酷的验证东西等等等，你可以使用，然后也许有一些有用的证据来支持那个位置（尝试过并且失败了）。

4

1 回答 1

2

我只回答有关 L&F 的部分问题，即 GUI 和安全性。

1) L&F Vaadin 6.x 版本不支持独立使用小部件。您需要进入整个服务器端模型。

但是，从版本 7 开始，Vaadin 倾向于旋转 Widget 端以允许使用小部件，而不会像服务器端状态维护那样被迫使用前后 jsf。参考 - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/3U1h0W_iHcM

2) Security GWT 端对 RPC 的 XSRF 特性提供了很好的支持，这将允许每个 RPC 调用或根据您选择的粒度选择性地生成 rpctoken。这可能是每个服务器端状态调用的 Vaadin 往返的性能开销。

3)GAE是影响depending您的 Vaadin 往返行程真正重量的一个因素。

4)Future

Vaadin 是 Jboss 的成员，GWT steering committee并且与 Jboss 一起Errai（asynchronous bean management在 Errai 路线图中）严重依赖服务器端模型。

于 2012-11-30T06:59:25.147 回答