hax
- 浏览: 974309 次
- 性别:
- 来自: 上海
-
文章分类
最新评论
-
sscsacdsadcsd：
mike8625 写道react还要自己的一些标签 还得编译 ...
对于React体系的一点想法 -
mike8625：
说的都是给大公司听的,国内很多还是小公司,做个小项目, 说实话 ...
关于国内前端和JS技术发展的乱想 -
mike8625：
react还要自己的一些标签 还得编译 编译吧浏览器端说还慢 ...
对于React体系的一点想法 -
u012814086：
下意识想到了Golang
JavaScript语句后应该加分号么？ -
xueduanyang：
我是水羊，年轻的时候觉得只要有好斧子就能做成好产品，各种产品都 ...
关于国内前端和JS技术发展的乱想
Javaeye论坛又谈到红岗同志了：http://www.iteye.com/topic/110484
我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。
有机会的话你去看看， sap visual composer 或者webdynpro
更本不用你考虑web客户端啊， server端
标准组件，标准交互方式是SAP屏蔽web和server的前提
没看董
也就是说你也无法很容易的去改变SAP组件的显示方式，交互行为，它都帮你定死了。而LZ事实上想说明的是如何处理web复杂多变的需求
有机会的话你去看看， sap visual composer 或者webdynpro
更本不用你考虑web客户端啊， server端
标准组件，标准交互方式是SAP屏蔽web和server的前提
眼高手低的人干的，前台ui都摆不平还设计个啥整体框架！
他花费了多大的力气我们不管，但是如果吹牛，或者瞪着眼睛说瞎话，我们总有发言的权利吧！
我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。
分享到：
评论
26 楼
kill_e680
2007-08-18
参与评论,并说不好的人,有多少个是真真正正去用了这个AOM的,告诉你们,我多年B/S开发经验了,现在用上了AOM,感觉还真的不错,有50%的好处,你们在批判着,我也不多说了,反正我用着,有大部份内容不同意你们有些人的说法,我说另外50%,就是UI组件,有了那些,并在将来不断完善,增加,将来甚至会由一些热心人士贡献出组件,使开发工作组件化,提高复用度,就像当年的delphi,满天的组件,好多东西不用自己重写,多美的一件事~~~
25 楼
Jekey
2007-08-15
rest是啥新咚咚阿？作者怎么言必提rest？希望不是带着有色眼镜看问题……
24 楼
darchen
2007-08-15
每一件事情,都是有重有轻,为了达到一定的目的,付出了对于另一方面沉痛的代价.
asp.net/Jsf 是想开发者拖一个控件就完事,是想开发者容易开发,它付出了"绑定"的代价.
其它类似的框架它要成为王道,结果是一大堆的配置,它付出了"复杂"的代价.
开发什么样需求的系统,用合适的武器.
lgx522: 总是关注你的发言,jdon javaeye
asp.net/Jsf 是想开发者拖一个控件就完事,是想开发者容易开发,它付出了"绑定"的代价.
其它类似的框架它要成为王道,结果是一大堆的配置,它付出了"复杂"的代价.
开发什么样需求的系统,用合适的武器.
lgx522: 总是关注你的发言,jdon javaeye
23 楼
lgx522
2007-08-15
多做几天Web的人都知道，复杂页面有框架不如无框架。
但这并不妨碍我们用框架解决90%的简单页面问题，至少可以提高规范性。
论坛上对JSF是一棍子打死的态度，这不可取。因为你们对JSF并不精通，以WebWork的思维定式来评判JSF，这相当不公道。每种技术都有其独特的技术思维，不深入实际使用是很难评判的。
JSF用了两年，大多数简单页面还是很容易做的，推荐初学者使用。
老袁的OperaMasks简单试用感觉还是很不错的，大家不要轻下决断。想深究的可以好好使用实践一下再评论不迟。
不服气的大可在你们热爱的框架上也扩展一套出来公布到开源社区，也让大家评判一下如何？
但这并不妨碍我们用框架解决90%的简单页面问题，至少可以提高规范性。
论坛上对JSF是一棍子打死的态度，这不可取。因为你们对JSF并不精通，以WebWork的思维定式来评判JSF，这相当不公道。每种技术都有其独特的技术思维，不深入实际使用是很难评判的。
JSF用了两年，大多数简单页面还是很容易做的，推荐初学者使用。
老袁的OperaMasks简单试用感觉还是很不错的，大家不要轻下决断。想深究的可以好好使用实践一下再评论不迟。
不服气的大可在你们热爱的框架上也扩展一套出来公布到开源社区，也让大家评判一下如何？
22 楼
JJYAO
2007-08-14
JavaVision 写道
JJYAO 写道
JavaVision 写道
hax 写道
Javaeye论坛又谈到红岗同志了：http://www.iteye.com/topic/110484
我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。
我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。
有机会的话你去看看， sap visual composer 或者webdynpro
更本不用你考虑web客户端啊， server端
标准组件，标准交互方式是SAP屏蔽web和server的前提
没看董
也就是说你也无法很容易的去改变SAP组件的显示方式，交互行为，它都帮你定死了。而LZ事实上想说明的是如何处理web复杂多变的需求
21 楼
JJYAO
2007-08-14
JavaVision 写道
hax 写道
Javaeye论坛又谈到红岗同志了：http://www.iteye.com/topic/110484
我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。
我就去看了一下OperaMasks的网站，看到了红岗和张勇的《勇敢者的新世界》。以下是我的comment。
看了前面的历史回顾，写得不错，我本对后面的java web framework部分充满希望，不料，第4节居然就寥寥几句，java世界如此多的开源和商业的web framework，居然作者提都未提，只说了servlet/jsp和古老的struts，连ASP.NET的描述也比它多。难道作者认为所有的读者都还停留在2001年？我看读者没有“审美疲劳”，是作者“记忆疲劳”了。
我不相信红岗和张勇你们没有看到过java世界web framework的欣欣向荣，仅仅列入Apache的就有webworks、tapestry、turbine，还有cocoon。也不用说像gwt、echo、dwr、rife、zk等，哪一个不是名声在外，连你们熟知的Spring都有Spring MVC来插一杠子，你们居然全都视而不见？我只能认为你们是有意略过。这就是所谓“选择性失忆”。其他领域我们不说，但对于技术人员来说，这是很不应该的。
然而不谈这些java领域的web framework，不把OperaMasks放在这样一个大舞台上与其他java web framework做做比较，你们就自夸OperaMasks是“from earth to the moon, and ready for Mars”，号称“在技术和思想上傲视群雄”，这就更未免有些可笑了。有自信是好事，但是不幸的是，我们不止一次看到自信沦为自大狂妄甚或无知。OperaMasks是不是也会如此？我不知道，我也不希望如此。
下面谈谈技术。
说老实话，OperaMasks要自夸，首先你要证明JSF技术的先进性。作为一个有超过8年经验的web开发者，我对于Sun官方的JSF，甚至Java社区众多的MVC框架和一些新兴框架，都有着深深的疑虑。众多企图抹平网络编程与桌面编程的鸿沟，企图让开发者完全不用了解B/S原理，企图服务器端掌控一切的所谓“简化”，实际上真的是web开发的方向吗？B/S的请求响应机制，HTTP作为无状态协议等，都是web编程的固有约束（参见著名的REST论文），而以ASP.NET和JSF为代表的技术方向，实际上是在背离和打破这一约束的道路上越走越远。掩盖web编程“复杂性”的“简化”事实上能真正简化问题吗？实际上为了掩盖复杂性，也许底层付出了更大的复杂性的代价。许多框架的前提是，开发者不需要陷入这些plumbing，可能对于许多应用来说确实如此，但是一旦开发者被迫陷入必须处理一些设计者故意忽略的问题，他可能会发现陷入了巨大的困境中。微软的winforms和ASP.NET就是这样一种模式的典型代表，如果默认提供的那些控件够用，一切ok，但是如果你想稍作改变，extends一下，就会发现陷入大麻烦了，只好去买第三方控件。而你去看看那些第三方控件，全部是自行实现的，没有一个是从默认控件继承出来的。而这些第三方控件与默认控件是否能和平共存互相协调呢，很有可能不行，或者是会产生一些奇怪的bug，这全赖于第三方是否对其底层有足够的经验和能力。也就是说，表面的简单，换回的是开发者对于系统内部复杂性的理解力的丧失和自行扩展系统能力的严重下降，开发者对于第三方控件，最终也只能“以貌取人”，面对的风险是极大的。
JSF或者说OperaMasks会不会这样呢？这很难说，但是我不太乐观。因为我深知web客户端编程的复杂性，直接的客户端Ajax开发框架如prototype、dojo、YUI、ext等尚在努力，而服务器端连这一层都要掩盖。掩盖复杂性不是做不到，但是要把这多层复杂性以优雅的方式隐藏起来，并且还能在需要接触内部的时候，优雅的显露出来，简直是mission impossible，到目前为止，我还没有看到成功的。OperaMasks可以吗？存疑。这里有篇blog：http://canonical.iteye.com/blog/106766，对于JSF有这样的结论：“所有问题的一个集中体现就是增加一个新的JSF组件绝对不是一件平凡的事情。”
我们再看看Render kit。说起来只要更换一套render kit，就可以Ajax enabled。理论上似乎可行，但是这很可能只是具有一点Ajax的皮毛效果而已。实际上，开发者丧失了许多控制，特别是架构上的控制。比如JSF能支持REST架构么？不仅是现实中，在理论上就存在困境。因为JSF的语义可能就与REST架构不匹配。
当然对于偶尔做web开发，以java编程为主的开发者来说，JSF是有吸引力，特别对于企业内部应用来说，也有一定实用性的。但是以web开发为主，特别是做大规模web开发的人来说，应该对JSF抱有警惕。因为，这种类型的开发简化，很可能是以各个部分之间的紧耦合为代价的。
我再摘录一段文字：“同样，这个世界还存在许多Ajax Framework，譬如dojo。我们并不否认这些Ajax开发框架的优秀，但是，与它们的优点同样明显的局限之处是：dodo之类的Ajax开发框架仅仅解决了客户端的问题，对任何服务器端逻辑，dojo无能为力。J2EE是一个整体，它不仅需要解决表现层问题，也要解决数据层和逻辑层的问题，JSF 是JavaEE 5.0的一个重要组成部分，这就使得Apusic OperaMasks不仅可以创建丰富的客户端体验，同时可以和JavaEE应用服务器结合，从而建立强大的服务器端逻辑绑定。”
事实上，你们所认为的局限性恰恰可能是我们认为的优点。为什么JavaEE要解决所有问题呢？会不会所谓解决整体的方案，实际上会把问题搞砸呢（最著名的例子是EJB）？如果把JavaEE限制在数据层和逻辑层，以web services（无论SOAP还是Restful的形式）提供出来，而由纯浏览器端技术来解决表现层，是否可能是一种更好的方案呢？比如REST架构所体现出来的松耦合、语义透明性、极高的可伸缩性，纯浏览器端Ajax框架所体现出来的高交互的用户体验、灵活性、以及不依赖於服务器端的互操作性。
对于JSF的忧虑或质疑，不是我个人，而是社区内普遍的声音，像是 What's wrong with JSF 之类的讨论已经不稀奇了，宣称 JSF is dead 甚至 officially dead 也随处可见。国外如此，国内也是如此。
最后，我赞赏OpearMasks的GPL开源和社区路线（但现在要更换协议，令人有点担忧）。Native Ajax支持确实也略有新意。但是这还远远不够，目前为止，说OperaMasks思想和技术有什么领先处，实在无法令人信服。我所看到的只是令人遗憾的选择性失忆。
有机会的话你去看看， sap visual composer 或者webdynpro
更本不用你考虑web客户端啊， server端
标准组件，标准交互方式是SAP屏蔽web和server的前提
20 楼
JJYAO
2007-08-14
当你只需要用到某个框架的有限功能时，你可能不需要深入其中的细节，而当你要的超出了框架支持的范围，那么你需要深入了解是在所难免的。而一般来说，框架缺强大，越抽象，那么你要需要花费的精力就更多。
JSF目前就是这样的情况。因为默认的UI组件不能满足项目的需要，就需要自己去扩充。而它的抽象机制，又使得扩展的门槛变的很高。当我们不能因为这个而否定了JSF的进步，组件化的web开发，带来的开发效率很功能的提升，是值的肯定和进一步发展的。
JSF目前就是这样的情况。因为默认的UI组件不能满足项目的需要，就需要自己去扩充。而它的抽象机制，又使得扩展的门槛变的很高。当我们不能因为这个而否定了JSF的进步，组件化的web开发，带来的开发效率很功能的提升，是值的肯定和进一步发展的。
19 楼
chris.lee
2007-08-14
每个demo看了下，ui控件真爽啊
不知这些的ui组件的扩展性如何？
提供的jee5的server和studio似乎不能下载啊！
不知这些的ui组件的扩展性如何？
提供的jee5的server和studio似乎不能下载啊！
18 楼
mvmouse
2007-08-14
一个framework好不好，不是一个人说了算，如果两年后能流行起来，就是成功
而能不能流行，要靠实力说话的
而能不能流行，要靠实力说话的
17 楼
neptune
2007-08-14
还是多看一下wicket和tapestry，特别是wicket。jsf这东西他怎样做，都是基于jsp标签，对于前台美工就是一个字“烦”
16 楼
jjx
2007-08-14
发现某些人真是自信心膨胀的可以啊,呵呵
15 楼
pppppp
2007-08-14
和seam有点像
14 楼
jianfeng008cn
2007-08-14
jiming 写道
也不要把 jsf 一棒子打死，他还是有很多方便的地方的。至少在理论上还是比较完善的。
我觉得他的主要问题是
1.写个自定义组件太费劲了
2.目前为止没有一个特别完善的 implemetation.
我觉得他的主要问题是
1.写个自定义组件太费劲了
2.目前为止没有一个特别完善的 implemetation.
眼高手低的人干的，前台ui都摆不平还设计个啥整体框架！
13 楼
gm8pleasure
2007-08-14
JavaInActoin 写道
一个大公司花这么大精力开发出来的东西，一定有它的用武之地，你觉得它不适合你，不用就行了，LZ花这么大篇幅用来批判它，有什么作用呢？
中国人搞个像样的开源项目，不容易了，少搞些窝里斗吧，真有精力就给这个项目提出一些建设性的建议。
中国人搞个像样的开源项目，不容易了，少搞些窝里斗吧，真有精力就给这个项目提出一些建设性的建议。
他花费了多大的力气我们不管，但是如果吹牛，或者瞪着眼睛说瞎话，我们总有发言的权利吧！
12 楼
JavaInActoin
2007-08-13
一个大公司花这么大精力开发出来的东西，一定有它的用武之地，你觉得它不适合你，不用就行了，LZ花这么大篇幅用来批判它，有什么作用呢？
中国人搞个像样的开源项目，不容易了，少搞些窝里斗吧，真有精力就给这个项目提出一些建设性的建议。
中国人搞个像样的开源项目，不容易了，少搞些窝里斗吧，真有精力就给这个项目提出一些建设性的建议。
11 楼
quaff
2007-08-13
我来说说tag的两宗罪.
1.tag的属性需要在tld里面一一指定,应该具有set的方法的属性默认包含在tld里面,再加一点特殊配置某个属性exclude,required,这样就可以节约很多冗长的配置代码,再高级一点还可以引入继承.
2.UI tag加入定制属性麻烦,比如要为input加入autocomplete="off",那些tag都是按照w3c的标准来决定有哪些属性,现在是ajax的天下,对html element加入自己的属性是很常见的需求.
在struts2里面可以比较方便的去掉这个限制,我已经提交jira
https://issues.apache.org/struts/browse/WW-2092
1.tag的属性需要在tld里面一一指定,应该具有set的方法的属性默认包含在tld里面,再加一点特殊配置某个属性exclude,required,这样就可以节约很多冗长的配置代码,再高级一点还可以引入继承.
2.UI tag加入定制属性麻烦,比如要为input加入autocomplete="off",那些tag都是按照w3c的标准来决定有哪些属性,现在是ajax的天下,对html element加入自己的属性是很常见的需求.
在struts2里面可以比较方便的去掉这个限制,我已经提交jira
https://issues.apache.org/struts/browse/WW-2092
10 楼
jjx
2007-08-13
不过兄弟对webform也没有用发展的眼光看
因为现在asp.net ajax ,理论上现在的webform已经非过去的webform了
还有,仔细看了你对winforms,asp.net控件的评述一段 ,深不以为然 ,不过懒的发起争论了
因为现在asp.net ajax ,理论上现在的webform已经非过去的webform了
还有,仔细看了你对winforms,asp.net控件的评述一段 ,深不以为然 ,不过懒的发起争论了
9 楼
hax
2007-08-13
To lordhong:
RDF和RSS1.0，不能和JSF相提并论。RDF的问题恐怕在于其xml表现过于复杂，另外从学术走向应用的脚步太慢。RSS更是一个复杂的话题。RSS1.0的主要问题在于其用了RDF而不是plain XML。对于RDF的接受度影响了RSS1.0的流行，因为开发者会错误的认为他们必须应付他们不熟悉的RDF。但是RSS1.0本身还是很好的，譬如模块化。RSS2.0从中吸取了不少。Atom的优势在于，它不仅是一个聚合格式，而且也包括API协议。我本人是喜欢Atom和RSS1.0（而不是2.0）的。
顺便再copy一篇对JSF的咆哮：
http://www.theserverside.com/news/thread.tss?thread_id=43899
JSF sucks...and has no hope
Posted by: Leo Lipelis on January 19, 2007 in response to Message #225695
I have some experience with JSF, now using it on my second project.
I will never recommend JSF again.
1. Tremendously and unnecessarily complicated lifecycle. It's required to understand in detail how the lifecycle works to do even relatively simple things (of course you don't need it for an absolutely trivial "hello world" type stuff, but in real life you need to know it for even a moderately easy business app).
2. HORRIBLE, HORRIBLE error messages. Terrible output from the logger. WARNING: blah blah??? what??? What exactly is the problem in human terms? What line of jsp is it happening at? What are suggested fixes? What part of lifecycle is it happening it? What is going???? SEVERE: blah blah can't find row = 0? What is that??? Where? table component? Which one? What line number? Etc.
3. SILENT errors... what the?? If you don't configure h:messages or t:messages, and in some cases even IF you configure them, some errors are subtly and silently swallowed. Is some event listener derailing execution? SHOW ME in the log! What's going on?? Silent validation errors? What is going on?? The default should be SCREAMING LOUD (with line number and suggested fix) error. You should have to configure it to turn it OFF (not to turn it ON).
4. Useless GUI support. We use BEA Workshop and it sucks horribly. All our pages look NOTHING like what we designed them! Tabbed pane renders each tab *below* the next tab. WHAT IS THAT??? That's horrible.
5. verbatim??? subview??? WHAT IS THAT JUNK??? This is 2007 guys, please! WAKE UP. Don't tell me "facelets". I download 1 framework and it should be complete. Don't tell me I need to download 5 other packages from various websites to make it actually useful??? Plus there aren't as many GUI choices for facelets as for JSF.
6. JSP sucks... I've had with JSP ever since 2000, why do I have to come back to it again and again??? (Oh, I know why, because big corps are not always brave enough to jump on something like Wicket or Tapestry...they want the "standard" and something "with a GUI").
7. Implementing a custom component is absurdly complicated. IT SHOULD BE TRIVIAL. GUI should enable and GUI-fy custom components automagically. Welcome to 2007. I shouldn't have to write any additional descriptors, jars, xmls, manifests, and whatnot to make it GUI-fied. That's absurd. Use introspection. Use convention. Use intelligence. Use well thought out design to infer everything that GUI needs to know. Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial.
8. What is going on with all the magic javascript? I hate it! For example, if I want to submit page on a radio button click, why do I need to use onclick submit() and also use valuechangelistener? What happens if I skip valuechangelistener? What is this not documented? DO NOT GIVE ME A DUMB STEP BY STEP RECIPE on how to do thing... EXPLAIN WHY I NEED TO DO IT LIKE THAT and what will happen if I don't do it exactly like that. Where is all that???
Forget AJAX...the basics are not working in JSF. When JSF can cover the basics, then and only then can we think about AJAX. JSF sucks at its very core. It's poorly designed. It's over-complicated. It's hard or impossible to debug. It has terrible error messages. It's full of magic and weird behaviors (like what the hell is immediate=true? why such a nasty hack is not necessary in any other framework I am aware of?)
I am annoyed. My buddy is constantly pushing me to .NET. I love Java. I want to stay in Java world. But JSF has opened a door for .NET on our team. I detest the developer and user-hostile and arrogant attitude of Microsoft. I can't say I am happy about the whole situation.
RDF和RSS1.0，不能和JSF相提并论。RDF的问题恐怕在于其xml表现过于复杂，另外从学术走向应用的脚步太慢。RSS更是一个复杂的话题。RSS1.0的主要问题在于其用了RDF而不是plain XML。对于RDF的接受度影响了RSS1.0的流行，因为开发者会错误的认为他们必须应付他们不熟悉的RDF。但是RSS1.0本身还是很好的，譬如模块化。RSS2.0从中吸取了不少。Atom的优势在于，它不仅是一个聚合格式，而且也包括API协议。我本人是喜欢Atom和RSS1.0（而不是2.0）的。
顺便再copy一篇对JSF的咆哮：
http://www.theserverside.com/news/thread.tss?thread_id=43899
JSF sucks...and has no hope
Posted by: Leo Lipelis on January 19, 2007 in response to Message #225695
I have some experience with JSF, now using it on my second project.
I will never recommend JSF again.
1. Tremendously and unnecessarily complicated lifecycle. It's required to understand in detail how the lifecycle works to do even relatively simple things (of course you don't need it for an absolutely trivial "hello world" type stuff, but in real life you need to know it for even a moderately easy business app).
2. HORRIBLE, HORRIBLE error messages. Terrible output from the logger. WARNING: blah blah??? what??? What exactly is the problem in human terms? What line of jsp is it happening at? What are suggested fixes? What part of lifecycle is it happening it? What is going???? SEVERE: blah blah can't find row = 0? What is that??? Where? table component? Which one? What line number? Etc.
3. SILENT errors... what the?? If you don't configure h:messages or t:messages, and in some cases even IF you configure them, some errors are subtly and silently swallowed. Is some event listener derailing execution? SHOW ME in the log! What's going on?? Silent validation errors? What is going on?? The default should be SCREAMING LOUD (with line number and suggested fix) error. You should have to configure it to turn it OFF (not to turn it ON).
4. Useless GUI support. We use BEA Workshop and it sucks horribly. All our pages look NOTHING like what we designed them! Tabbed pane renders each tab *below* the next tab. WHAT IS THAT??? That's horrible.
5. verbatim??? subview??? WHAT IS THAT JUNK??? This is 2007 guys, please! WAKE UP. Don't tell me "facelets". I download 1 framework and it should be complete. Don't tell me I need to download 5 other packages from various websites to make it actually useful??? Plus there aren't as many GUI choices for facelets as for JSF.
6. JSP sucks... I've had with JSP ever since 2000, why do I have to come back to it again and again??? (Oh, I know why, because big corps are not always brave enough to jump on something like Wicket or Tapestry...they want the "standard" and something "with a GUI").
7. Implementing a custom component is absurdly complicated. IT SHOULD BE TRIVIAL. GUI should enable and GUI-fy custom components automagically. Welcome to 2007. I shouldn't have to write any additional descriptors, jars, xmls, manifests, and whatnot to make it GUI-fied. That's absurd. Use introspection. Use convention. Use intelligence. Use well thought out design to infer everything that GUI needs to know. Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial.
8. What is going on with all the magic javascript? I hate it! For example, if I want to submit page on a radio button click, why do I need to use onclick submit() and also use valuechangelistener? What happens if I skip valuechangelistener? What is this not documented? DO NOT GIVE ME A DUMB STEP BY STEP RECIPE on how to do thing... EXPLAIN WHY I NEED TO DO IT LIKE THAT and what will happen if I don't do it exactly like that. Where is all that???
Forget AJAX...the basics are not working in JSF. When JSF can cover the basics, then and only then can we think about AJAX. JSF sucks at its very core. It's poorly designed. It's over-complicated. It's hard or impossible to debug. It has terrible error messages. It's full of magic and weird behaviors (like what the hell is immediate=true? why such a nasty hack is not necessary in any other framework I am aware of?)
I am annoyed. My buddy is constantly pushing me to .NET. I love Java. I want to stay in Java world. But JSF has opened a door for .NET on our team. I detest the developer and user-hostile and arrogant attitude of Microsoft. I can't say I am happy about the whole situation.
8 楼
kamiiyu
2007-08-13
openmasks的视频好吐血，竟然照搬黑客帝国，有版权问题吗？
7 楼
jiming
2007-08-13
也不要把 jsf 一棒子打死，他还是有很多方便的地方的。至少在理论上还是比较完善的。
我觉得他的主要问题是
1.写个自定义组件太费劲了
2.目前为止没有一个特别完善的 implemetation.
我觉得他的主要问题是
1.写个自定义组件太费劲了
2.目前为止没有一个特别完善的 implemetation.
发表评论
-
对于React体系的一点想法
2015-06-12 01:53 5993这一年来react和react native火得不行。 我对 ... -
图片lazyload兼容无脚本的小改进
2012-12-04 19:09 5892刚刚改进了一下某个页 ... -
tagName的大小写问题（QWrap选择器的一个bug）
2011-07-16 23:33 6573今儿写程序。 对于现 ... -
document.enableStyleSheetsForSet() 的兼容
2011-06-17 16:27 3545可能有不少同学已经了 ... -
IE神奇小bug一则
2010-12-03 18:05 2818<input type="text&quo ... -
前端优化新得一则
2010-02-22 15:05 2887因为把公司的电脑搞坏两台，这两天没有工作电脑可用了，所以就不干 ... -
一个史上最快的Web语法高亮引擎即将诞生
2009-05-02 03:33 6293对比对象是目前最有名，也是JavaEye所使用的highlig ... -
getUsedValue 0.4发布
2009-04-28 18:46 2106关于used value的基本解释，请看getUsedValu ... -
getUsedValue 0.1
2009-04-06 03:26 3734前不久写了一个小脚本，用来获取页面中CSS样式的 used v ... -
表单数据提交时的字符编码问题
2009-01-18 02:28 6260人老了，以前研究过的东西都忘记了。所以还是记录下来比较好。 ... -
再贴一次form的属性和控件name冲突的老问题
2008-11-07 18:59 3238更新： John Resig也谈到了这个问题。 而这里是一个非 ... -
一个嵌入式HTML引擎
2008-05-10 18:28 4168http://www.terrainformatica.com ... -
西方人通常发现不了的一个IE的bug
2008-05-09 20:00 9162这个问题我大概在一年 ... -
IE memory leak 备忘
2008-03-03 01:07 5250本篇只记录一下工具，有空再做研究。 Drip: http:/ ... -
批量修改style采取哪种方式好（续篇）
2008-02-24 19:20 4051前篇见批量修改style采取哪种方式好，主要是回答fins的提 ... -
XBL2的实现
2008-02-24 02:35 2423今天发现几种XBL2的实现。浏览器实现XBL2还要等上一段时间 ... -
批量修改style采取哪种方式好（答fins）
2008-02-23 21:55 4453fins同志向我提了个问题。因这个问题其实可以展开讨论，所以提 ... -
使用捕获事件监听器（useCapture=true）的陷阱及其对策
2008-02-17 07:02 9779DOM event flow有三个phase，capture、 ... -
写了一个XML Base的JS实现（简介篇）
2008-01-23 01:08 3207最近想在一个小应用中采用浏览器端的xinclude。找了一下， ... -
MSXML默认解析外部DTD
2007-11-07 18:17 3634昨日aimingoo说它测试xmldom的速度，发现载入一个w ...
相关推荐
operamasks-ui 最新.完成的，下载下来直接可以点击查看，跟官网一模一样
"Operamasks UI 2.0 Doc"是一个针对 Operamasks 用户界面的开发文档，它提供了详尽的指导和信息，帮助开发者理解和构建基于Operamasks的Web应用程序。这个离线版文档对于开发者来说尤其珍贵，因为在线寻找这类资源...
**Operamasks SDK 3.2：金蝶中间件的创新解决方案** Operamasks SDK 3.2 是金蝶中间件公司推出的一款重要的软件开发工具包，专为开发者设计，旨在简化与金蝶产品集成的过程，提高开发效率，并增强应用程序的功能。...
### operaMasks_studio应用手册知识点详解 #### 一、operaMasks_studio简介 **operaMasks_studio**是由金山公司开发的一款专业工具，主要应用于JSF（JavaServer Faces）项目的开发。该工具旨在提高开发效率，简化...
只是我在网上找的 operamasks-ui api 文档 , 希望对你们有帮助
"operamasks官方jsf教程"是针对初学者的一个资源，旨在介绍如何使用JSF和OperaMasks进行Web开发。这个教程可能是基于国外的原始JSF教程进行了适应性修改，特别强调了在Opera浏览器中的实践应用，这对于那些想要了解...
**OperaMasks安装包详解** OperaMasks 是一个专为Opera浏览器设计的扩展程序，它提供了丰富的功能，旨在提升用户的浏览体验。这个安装包包含了多个核心组件，让我们逐一解析： 1. **operamasks-comp.jar**：这个...
【标题】"OperaMasks查询、模糊查询、源码"涉及的是一个基于OperaMasks前端框架和后端servlet+bean技术实现的查询系统。在这个Demo中，开发者展示了如何运用这些技术来创建一个具备模糊查询功能的应用。让我们深入...
"Operamasks UI 2.1 Demo"是一个专注于前端用户界面的项目，主要基于流行的开源浏览器扩展框架——OperaMasks。这个项目的目的是提供一个演示版本，让用户和开发者能够体验和理解OperaMasks UI 2.1版本的功能和设计...
Apusic OperaMasks很全的JSF的例子，什么都有，如：TREE 、GRID、FORM、BOX、MENU、DIALOG、AJAX。都很漂亮的。
"Operamasks-faces_1.0" 是一个与Opera浏览器相关的扩展或资源包，它主要专注于面部识别或个性化功能。这个压缩包可能是为Opera浏览器设计的一系列面具或表情符号，让用户在浏览网页时能够使用各种有趣的脸部形象...
"Operamasks-UI" 是一个专为Opera浏览器设计的用户界面增强插件的源代码包，其版本为1.2，存储在一个名为"operamasks-ui-1.2.zip"的压缩文件中。这个插件的目标是提供更加个性化、高效且易用的浏览体验。在了解这个...
《深入理解OperaMasks UI 2.0：前端框架与应用实践》 OperaMasks UI 2.0是一款由金蝶公司推出的高效、易用的前端界面库，它旨在为开发者提供一套完整的用户界面解决方案，以提升Web应用程序的用户体验和开发效率。...
【OperaMasks快速进阶】文档详尽地介绍了OperaMasks这一开源Java框架，它由金蝶中间件公司的Apusic捐赠初始代码，并在OperaMasks.org开源社区不断成熟。OperaMasks是一个Web2.0框架，它以IoVC（Inversion of View-...
"Operamasks UI 2.0 Demo" 是一个专门针对Opera浏览器的扩展或应用界面设计的开发套件，主要用于创建和定制用户界面。这个压缩包文件 "operamasks-ui-2.0-demo--.zip" 包含了用于演示和实践如何使用Opera Masks UI ...
在IT行业中，Web开发是一项核心任务，而"operamasks整合spring、hibernate实现grid增删改查"是常见的Web应用开发实践。这个主题涵盖了多个关键的技术组件，包括OperaMasks、Spring框架和Hibernate持久化层，以及Grid...