是否为企业应用程序提供GWT

Question

我正在研究一种在app-engine上创建企业级应用程序的工具.这需要跨浏览器(也包括IE8),在移动设备上工作,并在以后的时间点也支​​持桌面客户端(Qt4/GTK /等)

我一直面临的问题是:对于我的网络应用程序 - 我应该使用GWT(GoogleWebToolkit)吗？

我很擅长使用"EXT-JS",但由于其开源政策,它不是一个选择.还有另一个框架"SmartClient",它具有更好的开源许可证 - 它相当成熟,比EXT-JS(基于一些POC)更好,但它的文档很糟糕!我需要花很多时间才能以正确的方式完成任务.SmartClient和EXT-JS非常适合企业级应用程序(正确使用时) - 我在Ext-JS中体验过这一点,并且对SmartClient非常肯定.

然后有这个组合"JQuery和插件和HTML5".与上面的库相比,我喜欢更快,更清洁,更小的JS.我对HTML5持怀疑态度,因为这是一个不断发展的标准

我真正喜欢GWT的是它的性能优势.至少这些例子看起来效果很好.我不喜欢它是Java,我非常擅长javascript对于我在app-engine上的服务器端应用程序,我不是在使用Java而是使用Python.所以rpc只能基于json.我们还没有移动版本,但这又是一个非常需要的版本,我们可能会在稍后使用Sencha-touch.

我已经完成了所有这些的POC,与extjs或smartclient相比,GWT部署感觉快速而顺畅.GWT会自动为我做很多事情.我也喜欢gwt渲染的"clean-html".我也很擅长使用javascript,并且非常清楚那里发生的导致javascript地狱的"错误".

(我不期待ExtGWT或SmartGWT)

有关我是否应该切换到GWT的建议,还是企业级应用程序的好事？

或者,如果有人经历过使用GWT构建大型应用程序,那么缺点(和专业人员)是什么？

Answer 1

对于已经拥有JSP/JEE和HTML/Javascript经验的人来说,GWT只需要半天的时间来理解.但是你需要两个月才能掌握.

以下是我认为可以使您的企业级应用程序成功的技术与GWT组合的建议.我认为你应该使用GWT,因为它的可调试性.但是可调试性是有代价的.GWT调试至少需要一台四核8GB机器.如果你没有发现这是真的,那可能是因为你找到了一种方法来使你的GWT UI小而简单.

在调试GWT应用程序时,Eclipse正在运行

RequiresResize,ProvideResize和Layouts

您需要在GWT中掌握的第一件事是布局的简单概念,这些布局由接口RequiresResize,ProvideResize决定.您需要确保从RootLayoutPanel到可调整大小的小部件的RequiresResize/ProvideResize链必须是完整的.您需要掌握架构检测UI中RequiresResize/ProvideResize的流程.否则,当浏览器调整大小时,您会看到一个或两个奇怪的悬挂水果,无法发现.

我认为应该不惜一切代价避免为每个小部件编写计划的大小调整器而不是依赖于Google的RequiresResize/ProvideResize.否则,请记住在几次迭代中去抖动调整大小.我完成调整大小的试验/错误太多了.

异步异步异步

你需要接受的下一个概念......我没有说"你需要学习",但"你需要接受"是Javascript的异步行为,因此也就是GWT Java的异步行为.如果您使用GWT无关紧要.您必须习惯于向被调用者提供控制反转以控制调用者的成功响应.

你不能写

List<Persons> persons = server.getData(personId);

你必须屈服于做

server.getData(personId, new Callback<Persons>(){
  @override public void onSuccess(Person person){ ..... }
  @override public void onFailure(Exception ex){ ..... }
});

你不能写

boolean doOrNot = ConfirmDialogBox();

你必须写

ConfirmDialogBox(new CloseHandler(){
  public void onAccept(Person person){ ...}
  public void onCancel(){ ... }
});

GWT是Java但不是Java

我很高兴不断尝试使用apache字节码jar来编译GWT客户端,GWT客户端是用Java编写的Javascript.

二进制数据和GWT

GWT可视化客户端

我找到的最好的组合是GWT 2.4.0和Sencha gxt 2.2.5.

我避免使用GXT-Uibinder项目,因为我发现它对第三方GWT框架的其他组合设置了不方便的限制.特别是那些严重依赖GWT.create()生成器的框架.GXT-Uibinder是Sencha之外的一个项目.

GXT 2.2及以下版本要求我编写包装器以使其可以与uibinder一起使用,因为我拒绝使用kludgy GXT-uibinder项目.由于一个愚蠢的错位,包装是必要的.在uibinder中用作父窗口小部件节点的任何类都必须实现GWT HasWidgets,这需要实现返回的方法iterator<Widget>.不幸的是,GXT 2.2--已经实现了返回错误的泛化迭代器的iterator()方法.

GXT 3解决了这个问题.我认为GXT 3采用了GXT-uibinder,但您不必使用它.您不必使用GXT 3(不使用GXT-uibinder)编写很多包装来与uibinder一起使用.但我发现GXT 3仍然有一些古怪的不端行为,试图解决这些怪癖是不值得我的时间.所以我坚持使用GXT 2.2.5,直到GXT 3稳定下来.

我创建了用于包装SmartGWT(uibinding-smartgwt)的谷歌代码项目.SmartGWT是一个非常自私的框架.如果我尝试将它与GWT香草混合,我的努力经常会导致灾难.这是由于SmartClient和GWT的小部件之间存在某种Z索引.

如果您因许可问题决定使用SmartGWT,则必须确保仅使用SmartGWT而不使用任何其他Widget提供程序.甚至不是GWT香草.你很可能需要使用我的uibinding-smartgwt项目.我想,以提高其使用一些新的特点UiBinder的重新定义和非视觉元素不被小部件,但我目前使用GXT的简直是太参与,并在同一时间去思考这两个框架混淆了我.因为他们的行为不同.

虽然GXT 3似乎已经完全与GWT保持一致,但SmartGWT并没有表现出任何努力.第三方窗口小部件提供程序与GWT之间的完全对齐,以便它顺利实现GWT的接口是绝对必要的,以避免浪费大量时间在kludges之后编写kludges来解决一些小的视觉问题.是的,尤其是ProvideResize/RequiresResize架构.

不要使用GWT孵化.尝试它们,然后尝试使您的项目可维护,可持续和可增强.我们甚至不去那里.

客户端 - 服务器通信

不要使用GWT-RPC.不要.学习GWT的便利性除外.

RPC适用于简单的应用程序,它们的作用是您无意延伸到演示阶段以外几乎无法使用的阶段.不编写分布式/扩展的企业级应用程序的程序员可能不同意我的观点.

单元测试对开发您的应用非常有帮助.首先忘记所有这些单元测试框架.只是能够编写一个简单的例程来测试每个小功能而不涉及应用程序巨大的巨大图片是非常关键的.例如,我只是想测试一个camelization循环以使其工作.GWT-RPC对于进行正式/非正式单元测试极为不便.

我很高兴在GWT客户端使用JAX-RS REST-RPC thro RestGWT,在服务器端使用RestEasy.我将JAX-B与RestEasy的Jackson JSON处理实现结合使用.而不是Resteasy,你可以尝试使用泽西岛.

通过这种方式,我可以使用FireFox REST客户端来独立于GWT测试服务器.实际上,在客户端使用GWT启动项目之后,您可以扩展应用程序以使用非GWT客户端(如JQuery)作为REST服务的客户端.

REST还使您可以轻松编写代理/隧道服务器,以便您克服浏览器的SLD-SO-P("二级域,同源"策略)安全限制.然而,GWT-RPC的数据格式是故意不可破译的和不稳定的(我不明白谷歌工程师的背后是如何提高安全性的心态,因为你仍然可以看到位和人类可读的文本块),我还没有尝试写隧道GWT-RPC服务的代理.我不知道它有多可行.

http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.

BTW,脚本包括克服sld-sop是非常糟糕的主意.甚至不要考虑它.

坚持

Hibernate JPA用于非GAE.Eclipselink JPA for GAE与Google的MySQL DataNucleus JPA for GAE with Google data store.

最初,我接受了JDO的想法.我努力了,JDO一直在给我冲突.我放弃.最初谷歌似乎一直在努力说服我们JDO是优越的JPA.无论是否真实,到目前为止我都未能掌握使用JDO持久性的技能.而且由于我必须为非GAE编程,我不想因为JDO的复杂性而污染我的思想.

我提到这个的原因是因为我倾向于使用与JAX-RS POJO相同的JPA POJO.这意味着,我发现JPA,JAX-RS,JAXB和Jackson注释混合到相同的POJO-DTO中而没有冲突.我经常在GWT客户端,JAX_RS服务器和JPA持久性之间共享一组POJO(有一些例外).要实现这一点,您必须有一个限制 - 所有DTO必须是GWT可序列化的.不仅可序列化.避免尽可能多地编写dto转换器.浪费时间有三组不同的POJO-DTO,然后在它们之间有转换器.

MVP

我发现MVP4G是一个非常容易管理的MVP框架.以下讨论演示了我如何使用MVP4G:

https://groups.google.com/forum/?fromgroups#!searchin/mvp4g/blessedgeek/mvp4g/T6r7egk-3Kk/Jz-dTqZDeMIJ

MVP是一种非常有用的模式.因为它可以帮助我区分"顾虑".当您能够分离问题时,您可以单独测试和解决问题.它还可以帮助您增强/扩展您的项目,同时尽可能少地干扰/纠缠您的迷宫应用程序的其他问题/模块.

MVP4G还可以轻松进行单元测试,因为您可以简单地模拟视图或演示者,或使用简化的事件总线/状态机来仅调试需要调试的部分.由于其模块化,您可以轻松避免污染非测试类,以便您可以删除测试源树而不会破坏生产类.IOW,您不必修改非测试类来测试它们.