2008-04-10

初看JSF后的胡言乱语

最近看了一点jsf ---- 只看了一点
看了一些网上的文章

看了 jsf in action 的如下章节:
1--3章
4 5章的部分内容
6--最后章节的标题


有很多疑惑:

1 jsf 能做的事情, 用标签做不出来吗? 一个过滤器/servlet + 一组标签 也能做出来吧?
有人能用尽量简短的语言来告诉我一下两者的本质区别吗?
(有状态bean 我觉得用标签都能轻易的实现, jsf事件机制我觉得根本就是一个错误的设计)

2 jsf所说的标准啊 模型啊 等等,有啥用? 是不是在这个标准下开发出的各种组件可以进行较好的替换? 例如我用了A厂商的jsf组件产品, 后来发现B厂商的更好, 我买来直接替换,那么我原先开发的程序基本上不用做大的改动就可以继续运行?


3 jsf和以数据为中心的B/S模式是不是冲突的?


4 有没有人和我一样, 看完关于jsf的介绍和基础例子后,就对它没什么兴趣了


5 我觉得,力挺jsf的人应该有3种:
(1) 出于商业目的
(2) 不了解ajax,html之类的前端技术,
(3) 不喜欢或不习惯b/s架构.
我这种想法对不对呢?有没有补充或反驳的?


以前对jsf一点不了解 ,所以从来都不是很在意那些批评他的文章,
因为我不喜欢轻易的批评我不了解的东西. 当然现在依然算不上了解.
不过 根据我已经了解的情况来看, 我根本没有兴趣对它做更多的了解.

如果JSF出现在VB DELPH盛行的年代就好了, 那个时代的人们也许更容易接受这样的东西吧
或者出现在B/S架构盛行之前(企业级应用刚开始从c/s过渡到b/s的时期),也是好的.

但是他选择了一个错误的时期,以错误的姿态出现, 很遗憾.
(sun似乎总是后知后觉,总是被形式"逼迫着"推出新的概念新的标准,一个没有前瞻性的公司, javaFX也是一例)


如果有一天JSF火了, 有人跑来跟我说, 看,现在是JSF的天下了.
那么我敢保证, 那时候的JSF肯定和现在的大不同, 也许只是名字未变而已.
评论
yyliuliang 2008-04-18
阳春白雪的东东用的人会很多吗?
JSF就是像asp.net 事件驱动的webform模型的学习之作
SUN本来就是商业公司,一切目的到头来还不是为了盈利啊
shihao 2008-04-16
想找一个可以解决高深java问题的人很容易
而找一个可以解决并不高深的ajax问题的人却比较难


这就是JSF流行的原因。
如果您是个html+js+css高手，您完全可以不用JSF
而我等不太会用的，只好JSF了。
比如，在页面上的那个日期控件，到了servlet就只有String 了，还不如JSF的convert简单呢
fins 2008-04-10
[quote=williamou ]
很明显就是ｓｕｎ出于商业目的搞出来的咚咚！
很明显！！
[/quote]
JSF 是sun 发现 自己的奶酪被动了之后 情急之下想出来的东西

而它接下来的工作 主要就是 用一个错误来修复前一个错误 周而复始 乐此不疲.

一座地基不牢的楼 就这样被越盖越高
badqiu 2008-04-10
支持，简单了解过JSF，整个感觉是比较magic,但magic也意味着在现在组件比较骓以扩展。
zhkchi 2008-04-10
最烦人的就是java的表现层了。。。无穷无尽的讨论。。。搞的选择谁都很头大

以前struts是首要选择，选择呢？tapestry webwork2 struts2 jsf velocity 等等。。。哎。。。很烦很痛苦！
fins 2008-04-10
引用
可维护性和开发效率

这个是与技术水平相关的

有个事实你不得不承认:
java语言的普及率和受重视程度 绝对大大远远的超过了js+html+css 这一套东西

这种情况在一定程度上造成了:
想找一个可以解决高深java问题的人很容易
而找一个可以解决并不高深的ajax问题的人却比较难

进而造成了一个误解: ajax项目难维护等问题

当然 ajax的弱项很明显

但是单单就ui来说 jsf怎么肯能更好呢?


用java来生成html+js+css层面的东西, 然后用java来处理发生在 html+js+css层面上的事件

怎么可能比在html+js+css层面内部做这件事 更好呢??


注意: 以上言论只针对 b/s系统来说 , 我知道jsf不仅仅可以用在B/S系统中
williamou 2008-04-10
很明显就是ｓｕｎ出于商业目的搞出来的咚咚！
很明显！！
chenjf2k 2008-04-10
同感！JSF好像只是在模枋.net的控件事件技术，与.net webForm控件技术相比，其开发工具和开发效率远远落后...
terranhao 2008-04-10
反正至少我是认为,jsf用熟了是相当的high.
不过运行速度可能会低一些,不过在开发效率可维护性和运行效率的权衡上,我还是选前者,因为速度慢我可以加服务器啊,可维护性和开发效率才是成本的最大头.一个人2月的工资就可买一个小服务器了,呵呵
terranhao 2008-04-10
看你做什么应用了,如果指是针对一般的应用,没有太丰富,太复杂的UI
只是普通的ajax应用那使用jsf+richfaces将极大提高开发效率.开发效率和struts几乎是档次性的差别.
而且后期维护性也相当容易.
但如果界面太复杂,那还是老老实实用ajax框架吧
fins 2008-04-10
其实我主要是站在 UI层开发者的角度来看的
我也承认 jsf能解决很多 纯ajax组件不能解决的问题
而且jsf和ajax组件不冲突 例如在技术和理论上jsf可以和ext很好的整合

但是单单就"UI层开发"来讲 jsf本身肯定不够好

开发一个组件的难度太大 使用成本太高
sword721 2008-04-10
jsf基于組件的思想還是不錯
畢竟隻是一個工具而已.
fins 2008-04-10
现在是一个变革的时期,没有谁是一统的.

从技术角度讲, 我觉得还是纯ajax框架更适合做表现层.
表现层和后台应该充分解耦, 以数据为中心.

从效果讲 , Flex肯定是最好的


关于未来不好说,
我觉得 html 5, js 2 这些东西出来后, 这个市场也许会面临重新洗牌的.
high_java 2008-04-10
那你觉得在表现层现在是谁的天下呢？
发表评论

您还没有登录，请登录后发表评论

fins
  • 浏览: 706212 次
  • 性别: Icon_minigender_1
  • 来自: 小胖儿的大城
  • 详细资料
搜索本博客
我的相册
D491c37e-81de-385c-ad95-b7a20ad6a3c8-thumb
David Recordon
共 63 张
其他分类
存档
最新评论