从下面的框架列表中,您将使用哪一个开发一个丰富的Web应用程序,以及为什么您会选择其他应用程序?哪个Web应用程序框架?
SproutCore的 GWT ExtJS的 GXT SmartGWT的 道场/ Dijit的 的Flex 卡普琴糯 Grails的
从下面的框架列表中,您将使用哪一个开发一个丰富的Web应用程序,以及为什么您会选择其他应用程序?哪个Web应用程序框架?
SproutCore的 GWT ExtJS的 GXT SmartGWT的 道场/ Dijit的 的Flex 卡普琴糯 Grails的
这些都是基于使用你所提到的框架,我个人的经验。所以,是的,这是一个有点偏。因此,正如其他人说了一遍又一遍,确定您的要求和其根据人们在此提出的建议,您认为一个符合您的要求:
你确定你已经看过GWT足以评论它的简单性吗?我刚刚开始使用它,实际上我很惊讶它的清洁和简单。 – 2010-03-18 16:09:40
这些天来人们使用GWT和MVP模式,这个模式太冗长而复杂。 – 2010-03-18 21:16:22
这是严格见仁见智。你不会得到任何人的明确答案,因为任何人的答案都会有他们个人喜欢的。
尝试每一个足够长的时间来决定哪一个最适合您(或您的团队)的目的。
这就是说,我更喜欢GWT。其他人总是不同意我的看法。
的原因,我喜欢GWT:
UiBinder
允许您使用声明式HTML语法编写您的UI;如果你不想要的事情,可能使GWT不适合你:
我目前工作的一个圣杯/柔性混合应用程序这比我预期的要好得多。我曾看过GWT,但当时没有太多关于它的书,它似乎强调了我从来不喜欢的类似Swing的编程技术的利用。我同意关于全部尝试的评论。运行他们都有的应用程序,并测量它的修改难度或容易程度。此外,工具(IDE,Maven,CI ...等)的支持也可以成为立即生产力的重要因素。
不幸的是,答案将是自以为是的,GWT的最纯粹的形式不是一个眼睛的糖果。这就是说,ExtJs GXT超级豪爽。我面对不断变化的框架所面临的一个主要问题是它们不是绝对没有缺陷的,如果我没有记错的话,那么GWT 2.0就会出现一些新的布局缺失的CSS样式。我试图从最近5天开始在ExtJs/GXT中遇到问题:(框架混淆了很多东西,我将使用任何绝对健壮的框架,并给出相应的错误消息,尽管我没有与其他人一起工作
我个人对浏览器的不一致感到厌倦,如果别人已经解决了问题,我宁愿不要再这样做,这就是为什么我对前端如卡布奇诺和qooxdoo更感兴趣。零HTML零CSS的解决方案。
我们使用Grails这里+ ExtJS的。由于我们试图制作一个惯用的ExtJS应用程序,所以Grails没有得到充分的利用,尽管在服务器端部分使用Grails而不是JSP可能是有意义的。
为什么选择ExtJS:因为它是一个非常丰富的类似GUI的Web应用程序工具包。我们的工作是替换旧的Motif GUI,所以这正是我们需要的。
为什么选择Grails:因为它可以轻松快速地完成工作。对于ExtJS的部分通信,就需要大量的JSON,并在Grails的是这样的:
import foo.bar.FooBar
class FooBarController {
def viewFooBars = {
def list = FooBar.getList(session.userId, params.foo, params.bar)
def result = [resultset: list] as JSON
response.setHeader('Content-disposition', 'filename="json"')
response.contentType = "text/json";
render result
}
}
而这甚至二,三线超过必要的...
分机GWT已经工作以及我的项目。高级支持一直很好。
但是该项目是内部使用的,它允许在一个操作系统上将部署限制在一个浏览器上,并且没有努力改变Ext GWT的默认外观或行为。
完全在Java内部开发是一项关键的好处,因为它有助于在添加功能时保持项目的可管理性。
ExtJs非常适合创建复杂的Web应用程序。这个API提供了任何你可以在webapp中想象的东西,并且在一段时间之后很容易扩展任何组件。
您可以将它插入任何后端(我们使用django或php),并在几个不同的应用程序中重用或扩展任何组件。
您需要几个月才能感觉舒适。恕我直言。
这就是说,lib有时对于像网站这样的简单用户来说太慢了(那么你可以使用ExtCore)。但是,当涉及到web应用程序,这不是一个问题。
我不是一个java的家伙,所以GWT是不是一种选择对我来说:/
希望这有助于
我建议道场。
除了提供的大量基础架构外,Dojo 1.6也是第一个(也是唯一)流行的JavaScript库,可以成功地用于Closure Compiler的高级模式,并且所有的大小,性能和混淆优势都附加在它上面 - 除了Google自己的Closure Library之外,就是。
换句话说,使用道场的程序可以是100%的混淆 - 即使库本身。
编译后的代码与纯文本代码具有完全相同的行为,除了它比规模更小(平均值比平均值高25%),运行速度更快(特别是在移动设备上),并且几乎不可能进行反向工程,甚至在通过美化器之后,因为整个代码库(包括库)都被混淆了。
只有“缩小”的代码(例如YUI压缩器,Uglify)可以在穿过美化器后轻松地进行反向设计。
什么?没有电梯?电梯和GWT一起美味。添加一些谷歌应用程序引擎的面食基地的混合和重击,你有自己的营养晚餐。 – 2010-03-18 05:15:15
Downvoting this question?这不是一个*坏问题*它只是不太可能会有任何明确的答案... – 2010-03-18 05:30:59
我同意不可能有一个明确的答案,但让人们对这些框架的意见在一定程度上肯定是有用的。我会接受所提供的最翔实和客观的答案。 – Fergal 2010-03-18 05:55:21