[@gwt.eventArgs之前用作]针对RPC的基于javadoc的元数据。这是一个很棒的示例,由于当晋级到GWT1.5时,年夜多半人一入手下手城市碰到这个变更。RPC如今变得更复杂也更丰厚,由于RPC接口能够复杂地指定泛型汇合。另外一个值得注重的事变就是GWT1.5如今已完整撑持“long”原始数据范例了。在GWT1.5之前,“long”并没有失掉真正撑持,由于JavaScript没有64位的整数范例,因而利用当地的JSnumber其实不能暗示“long”的全体局限。在GWT1.5中,我们经由过程发生分外的代码来确保long的举动是完整准确的,只管在功能上要比GWT1.4略微低点。这是不成制止的:我们必需在功能和准确性上做出决定,明显我们会选择后者。假如你在GWT1.4中大批利用了long范例而且速率要比数字局限加倍主要的话,请思索将这些变量改成“int”大概“double”以坚持与GWT1.4一样的速率。
GWT编译器前端重用了Eclipse供应的优异的Java编译器。它处置一切的剖析和语法反省,然后构建一个笼统的语法树(abstractsyntaxtree,即AST)。接上去我们利用该AST举行优化并天生JavaScript输入。Eclipse编译器让我们变得加倍轻松,由于它处置了大批事情。可是,追求在JavaScript中无效地表达新观点的体例,如列举和加强的for轮回,仍旧消费了我们大批的事情。新的言语特征还对GWT库起到了主动的连锁反响,最分明的就是在RPC中可以利用泛型这个新功效,我们还对注解举行了扩大以鄙人面这些情形中取代基于javadoc的元数据体例:国际化、图象包和基准。
关头点:GWT赐与你良多,可是它不想酿成一个“围墙花圃(walledgarden)”。任何笼统城市有漏掉的工具,以是最好承受这个现实。我们成心简化该笼统,如许你就能够触及JavaScript的详细细节,那末你就能够集成你喜好的任何其他手艺了。这类天真性关于GWT自己和其用户来讲都是一种保险单:你能够断定你能将任何客户端手艺与GWT集成,同时我们(GWT开辟小组)也不用显式地将其与开放的工具举行集成,由于你老是能够本人完成这件事而不用等我们来完成。关于我所提到的天真性的示例,请参考RayCromwell的事情——Syndroid。
我们将持续存眷功能改善和将要从GWT孵化器中出来的几个新widget,包含一个日历控件和几个大度的表格widget。我们还在动手做别的完整奇怪的工具,如声明式的基于XHTML的UI模板机制。我们还没有企图好统统,但我希冀在随后一个或两个版本中能将其加出去。特地提一下,我但愿它的开辟周期比GWT1.5更短。
欢迎光临 仓酷云 (http://www.ckuyun.com/) | Powered by Discuz! X3.2 |