Dan*_*son 8 gwt google-app-engine vaadin
Vaadin网站上的GWT页面有点稀疏:https://vaadin.com/gwt
"只有好处,没有陷阱你将在GWT中享受你喜欢的一切,并获得新颖的服务器端编程模型,组件,工具,主题和其他附加功能的额外好处.如果你不喜欢你所看到的,那很容易只要你坚持使用com.google.*包就可以返回.你最终可能会开始使用com.vaadin.*包中的功能.但是没有必要担心 - Vaadin Framework也是在同一个版本下发布的自由派Apache 2.0许可"
我喜欢Vaadin网站上的一些外观和感觉,但我对"服务器端模型"感到紧张......如果可能的话,我宁愿让大部分代码在客户端运行,我正在检查GWT RPC再次调用(通常使用相同的java代码)以确保安全性.我不喜欢很多来回的想法.
鉴于我的担忧,是否值得深入挖掘Vaadin？还是我到此为止？我可以利用各种外观和感觉而不会让所有东西都陷入困境吗？任何其他关于杠杆作用的非直观答案都将受到赞赏.
更新:请不要回答比较Vaadin和GWT的问题,提供替代的UI框架.
我还使用了SmartGWT,GXT和捆绑的GWT小部件等.还熟悉一些非常完整的小部件集,如DevExpress for .NET.我问这个问题的原因是因为Vaadin LOOKS非常酷......我正在寻找这样的答案:不,不能从Vaadin中提取L&F而不影响客户端或者除了L&F之外,还有很酷的验证资料等等你可以使用的等等,然后可能是一些有用的证据来支持这个位置(尝试和失败).
我只回答有关 L&F 的问题的一部分，即 GUI 和安全性。
1) L&F
Vaadin 至 6.x 版本不支持独立使用 widget。您需要了解整个服务器端模型。
然而，从版本 7 开始，Vaadin 依靠 Widget 端的旋转来允许使用 Widget，而不必被迫使用像服务器端状态维护那样的来回 jsf。参考 - https://groups.google.com/forum/?fromgroups=#!topic/google-web-toolkit/3U1h0W_iHcM
2) Security
GWT 方面对 RPC 的 XSRF 功能有很好的支持，这将允许每个 RPC 调用生成 rpctoken 或有选择地根据您选择的粒度生成 rpctoken。这可能是每次服务器端状态调用 Vaadin 往返的性能开销。
3)是决定您的 Vaadin 往返行程实际重量的GAE一个因素。depending
4）Future
Vaadin 是 Jboss 的成员GWT steering committee并与 Jboss 一起Errai（asynchronous bean management在 Errai 路线图中）严重依赖服务器端模型。