|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-04-18
引用 没把你当白痴，只是觉的你挺能忽攸的，喜欢比喻但又牵强，喜欢强辩但又说不到点子上。 我写这篇文章 只是表达一下自己的想法 没有任何目的 也没指望这篇文章弄够影响到别人 也从来没有试图改变别人的想法 "忽悠"从何谈起呢? 关于这个问题我没法说道你所谓的点子上 因为我说的"点子"你看不到 而我之前针对JSF的那些质疑 也没有人能解答 (我怀疑你没有认真的看完每篇回复 看完主贴就来炮轰我来了) xyz20003 说的很对 引用 价值观不一样，这个论不好辩啊。 |
| 返回顶楼 | |
|
发表时间：2008-04-18
lcllcl987
不明白 为什么反驳我文章观点的人总是习惯 通过贬低我的方式 而不是 对于我对JSF的那几点质疑给出回应 唉 我到底狭隘与否 不是你说的算的 |
| 返回顶楼 | |
|
发表时间：2008-04-18
fins:
几年前我觉得自己会用tomcat开发OA,觉得自己会J2EE,后来直到有人当我面说"Tomcat just a toy",直到现在已经开始渐渐改变我的观点.到现在我是最后一帖, l987,1949,不管是不是马甲,觉得还是赞成他们说的多一点点. 搞java快8年了,还是不明白J2EE是啥玩意,不是指那些技术名词和技术实现,而是它为啥要那样子,出J2EE标准为了解决什么问题.我觉得这样能帮助你理解JSF为什么要那么做. |
| 返回顶楼 | |
|
发表时间：2008-04-19
J2EE jsf 要解决的问题我想我还是明白一些的
快速开发 机械化生产 符合标准 统一 规范.... 但是JSF要达到这个目的不一定非要像现在这么设计吧? 换个角度 B/S解偶 之间尽可能的只用数据做桥梁 这种设计难道就达不到 快速开发 机械化生产 符合标准 统一 规范....吗? 如果JSF能够快速的开发出后台业务逻辑 同时能够快速的开发出前台展现. 前后可以更好的解偶,为开发和测试提供更大的便利 同时提供一定的灵活性(可扩展 可替换) 这样不好吗? 难道这样就影响快速开发了? 我总结一下jsf的优点: 借助出色的IDE,可以帮助"代码机器"们快速的构建起一个可用的项目. 而且这个项目并不复杂,无需开发人员扩展jsf的组件. 除了这些还有什么呢? 我前面说过, 我做一个展现2维表的web页面 测试的时候 我需要安装jdk tomcat myface eclipse... 这个正常吗? 我希望的是 我可以在简单的文本编辑器里编写代码,在浏览器里测试运行, 测试时的数据我可以使用xml或json轻松传给列表组件 这样的做法不好吗? 也许有人会说 jsf有很多组件 列表组件现成的 不用你开发 不用你测试 不用... 对不起 请打住, 你是jsf的user 我是developer. 而且jsf那些组件我看过很多, 我很差异 为什么很多人都说那些组件足够用了呢? 我很奇怪 那些说组件够用的人做的是什么项目. 是不是只是一些对数据库记录的 查询和 简单编辑? 我以前和现在所在的公司都对jsf进行过考察,说实话 没有一个组件包是够用的 想满足我们验证项目的需求 我们用来验证JSF的项目是: 某电信BSS系统 , 某公司人事管理系统, 某应用管理系统(类似websphere的web控制台) 想实现我们的需求,要从各个组件包里提取各种组件进行组合 而且还要自己扩展很多 我真的很好奇 那些说现在的jsf组件已经够用的人 做的是什么项目 |
| 返回顶楼 | |
|
发表时间：2008-04-19
回你的贴还真有点麻烦,发现你真的挺能说的,所以这是最后一贴.
我写这篇文章 只是表达一下自己的想法 没有任何目的 也没指望这篇文章弄够影响到别人 也从来没有试图改变别人的想法 "忽悠"从何谈起呢? 写文章我觉的不是自娱自乐,比如说,我回你的贴就是不想让你那些偏颇的观点误导别人. 你说没指望能够影响到别人,也从来没有试图改变别人的想法,真的是这样吗? 说你忽悠,是因为你总是拿什么”解耦”,”B系统”,”S系统”,什么”伟大发明”,用在B/S系统开发的场景,关键时候就来一通. 这不是什么发明创造,这就是在忽悠,最好使用正常的技术语言讨论技术问题. 关于这个问题我没法说道你所谓的点子上 因为我说的"点子"你看不到 而我之前针对JSF的那些质疑 也没有人能解答 (我怀疑你没有认真的看完每篇回复 看完主贴就来炮轰我来了) 看了你对JSF的质疑问,还真的不知道怎么解答.因为你的问题我几乎都不太能确定你的意思. 你在对JSF非常不了解的情况下,问出下面问题有意义吗?不过,勉为其难,我还是想尽力答一下. 1 JSF UI和JSF其他地方结合太紧密 2 JSF开发UI组件很麻烦 3 JSF没有足够出色的组件实现 (比开源免费的 纯ajax的 EXT更好的 ) 4 JSF导致ui层和后台无法做到以数据为中心 1) JSF本来就是要实现Http Request统一的,规范的,以事件驱动方式的处理,Web Server和Browser之间传送http request(上传)和html(下传),不亲密点行吗? 2) 实际情况是,作为普通开发人员,根本不用自己去开发,拿来使用或扩展即可. 你使用Ext不也是只是使用吗? 你也不需要去开发,道理是一样的. 3) 最重要的一点(这个要你好好学了JSF才能理解)是: 标准JSF UI组件达不到类似Ext的效果,灵活性(比如说频繁和服务端交互)的原因是: JSF UI组件的数据(MVC中的Model)都在Web Server Session中,要改变或获取只能靠Http request/response的方式; 而Ext之类组件的数据全部都先取到Browser中,或动态通过Ajax获得. 如果你说这个是JSF的不足,也对,但这也是JSF的核心观念之一,Web Server保存其数据(Component Tree),Browser负责Render Html(数据来自component tree ). 当然,现在有了RichFace之类的技术已经能弥补这个不足. 4) 无法以数据为中心? 又来这个,为啥就不好? 给个理由先. 千万不要说切换前台或后台会比较方面. J2EE jsf 要解决的问题我想我还是明白一些的 快速开发 机械化生产 符合标准 统一 规范.... 但是JSF要达到这个目的不一定非要像现在这么设计吧? 换个角度 B/S解偶 之间尽可能的只用数据做桥梁 这种设计难道就达不到 快速开发 机械化生产 符合标准 统一 规范....吗? 上面这段又开始扯了,认真学习JSF两个星期,你就知道你讲这些简直是蜚夷所思. 如果JSF能够快速的开发出后台业务逻辑 同时能够快速的开发出前台展现. 前后可以更好的解偶,为开发和测试提供更大的便利 同时提供一定的灵活性(可扩展 可替换) 这样不好吗? 难道这样就影响快速开发了? 看到这里,我已经快不能承受了. JSF和开发后台业务逻辑能搭的上吗? 连最基本的JSF原理都没有搞明白,在这里说JSF为什么不能做的更好?不觉的好笑吗? 我总结一下jsf的优点: 借助出色的IDE,可以帮助"代码机器"们快速的构建起一个可用的项目. 而且这个项目并不复杂,无需开发人员扩展jsf的组件. 我使用JSF 1年多,从来没有借助过IDE来完成JSF页面组件的使用,自己写就行,组件的使用很方便. 除了这些还有什么呢? 实不相瞒,真的还有挺多. 我前面说过, 我做一个展现2维表的web页面 测试的时候 我需要安装jdk tomcat myface eclipse... 这个正常吗? 除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了? 我希望的是 我可以在简单的文本编辑器里编写代码,在浏览器里测试运行, 测试时的数据我可以使用xml或json轻松传给列表组件 这样的做法不好吗? 这样做是挺好的,等你这头(B系统)调好了,准备和那一头(S系统)调试的时候,S系统不需要安装JDK,tomcat和服务端程序, controller, Json-libarary, something like that? 我都怀疑你都没有用Eclipse,such a great IDE. 也有专门针对JSF的测试工具,单元测试,集成测试应有尽有. 在文本编辑器里敲代码,你觉的Cool,我一点也不觉的,过时了. 也许有人会说 jsf有很多组件 列表组件现成的 不用你开发 不用你测试 不用... 对不起 请打住, 你是jsf的user 我是developer. 是否意味着你发现Ext不能满足你的时候,你也自己Develop? 如果JSF 能提供80%以上的组件给你用,你觉的值吗? Reuse的价值很大,况且JSF绝对提供了良好的组件扩展方式. 而且jsf那些组件我看过很多, 我很差异 为什么很多人都说那些组件足够用了呢? 我很奇怪 那些说组件够用的人做的是什么项目. 是不是只是一些对数据库记录的 查询和 简单编辑? 我其实想象不出来,你那些系统都要有什么功能? 我和很多人的说法一样,足够了.毕竟,我们开发大部分B/S系统都是普通的管理信息系统. 我以前和现在所在的公司都对jsf进行过考察,说实话 没有一个组件包是够用的 想满足我们验证项目的需求 我们用来验证JSF的项目是: 某电信BSS系统 , 某公司人事管理系统, 某应用管理系统(类似websphere的web控制台) 想实现我们的需求,要从各个组件包里提取各种组件进行组合 而且还要自己扩展很多 我真的很好奇 那些说现在的jsf组件已经够用的人 做的是什么项目 你讲这些一点都没有说服力. 我就问一个简单的问题: 目前Java世界里, Web层开发技术到底是怎么分布的? 1) JSP 2) Struts, JSF, Spring MVC 3) Ext,Dojo,YUI …… 4) JavaFx,Flex... (可能未来不久会流行) 以下是我的判断和体会: 目前,JSP还有一部分, Struts绝对是主流,因为比较成熟和被广泛使用,你去看到处招人都是精通SSH就知道了. JSF是作为Struts的替代品而来的(Struts的作者是JSF规范的主要制定者),来的晚,但技术及理念上要比Struts先进(即使是Struts2还是摆脱不了form驱动,UI没有组件化的问题),所以,JSF比例会逐渐提高. Spring MVC大部分情况只是被用做Controller. 至于Ext,Dojo这一类基于Javascript的架构,会有一部分系统,比如那些有很高用户体验要求,操作复杂灵活的,但功能相对较少系统会采用. 但在大型的管理信息系统中采用的比例不会太高,这样的系统最终还是会选择开发效率高,易于维护,基于标准的技术,比如JSF, Struts. |
| 返回顶楼 | |
|
发表时间：2008-04-19
to fins
>J2EE jsf 要解决的问题我想我还是明白一些的 >快速开发 机械化生产 符合标准 统一 规范.... 历史原因,公司里有三个产品,其中一个是JSF做的,其他两个是"历史沉淀"的杂牌军. 后来公司里需要做一个整合,把三个系统集中到一个portal服务器,由portal提供更好的用户体验. jsf可以不用做任何改动,只要在portal容器中配置对应的portlet就OK了.那些历史沉淀就傻了.没有任何褒贬的意思,只是一次经历.感觉标准还是非常好的东西. 还有关于权限验证的经历,一直觉得JAAS巨麻烦.快速应用开发,还不如自己写ifelse来的快.是的,ifelse贪图一时快乐,很有效果.就像楼主所说的,拿个文本写个html就马上能看到效果.但是产品继续做,继续维护和升级,继续和更多的外部产品整合,那些快捷的方案都会疯狂了. EXTJS是个很好的东西,他的API也很优雅,但是他绝对不是展示层的解决方案,注意我所说的是解决方案.用它写桌面浏览器的的portal也很酷,也可以用它在jsf输出的添加一些更好的用户体验(但是我更愿意采用DOJO),或是写几百行的javascript,给浏览器中的html添加一些很酷的效果.但是这些都只能是pc浏览器,而在手持设备上,就不能采用这种方案了,而jsf则可以继续用. 假如本身带着挑刺的观点去看一个东西,会发现,它是越来越讨厌,而忽略了他的迷人之处. 很少参与JE的讨论,感谢fins发起这个话题,让我们对"事物"本身有了更多的思考和了解. |
| 返回顶楼 | |
|
发表时间：2008-04-19
我来帮fins解释一些东西吧，或者说我的观点吧，希望能有人看到：
引用 我使用JSF 1年多,从来没有借助过IDE来完成JSF页面组件的使用,自己写就行,组件的使用很方便.
你不借助IDE不是放弃了JSF的最大优势么？你使用方便不等于你的下属使用很方便。 引用 引用 我前面说过, 我做一个展现2维表的web页面 测试的时候 我需要安装jdk tomcat myface eclipse... 这个正常吗?
除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了? 这一看就是你没明白fins的意思，呵呵，其实很多时候要先做售前项目，或者是先做UI设计，就非常有用了。 有可能你们公司是做外包的，不担心需求的问题。 或者说，需求先行能解决很多需求理解行的问题，试想一下开发过程，系统解耦优秀的话，可以非常方便的让UI工程师先把界面做出来而不依赖任何服务端的代码，进行需求确认，或者说是敏捷思想的小步迈进，是非常重要的，这个时候发现需求理解有问题，返工的工作量要比后台都搭起来以后要小很多。 引用 这样做是挺好的,等你这头(B系统)调好了,准备和那一头(S系统)调试的时候,S系统不需要安装JDK,tomcat和服务端程序, controller, Json-libarary, something like that?
同上。 引用 是否意味着你发现Ext不能满足你的时候,你也自己Develop? 如果JSF 能提供80%以上的组件给你用,你觉的值吗? Reuse的价值很大,况且JSF绝对提供了良好的组件扩展方式.
自己参照EXT的框架和规范，或者其他方法Develop的成本不大的，因为选择余地很大。JSF 能提供80%以上的组件是你认为，我不认为。这个“能”是有歧异的。 引用 我其实想象不出来,你那些系统都要有什么功能? 我和很多人的说法一样,足够了.毕竟,我们开发大部分B/S系统都是普通的管理信息系统.
我进一步怀疑你们是做外包的。我认为即使大多数人甚至与我自己都不认为界面花哨有啥用，但是客户，客户验收人员，客户负责人的老板，我们自己公司的上层和老板就是喜欢，嘴上从来不承认，但是可以观察出来的。界面优秀的作用（实际的例子）有机会我单独发帖说明（我比较懒，还没单独发过帖，怕没人看啊，浪费啊）。 引用 JSF是作为Struts的替代品而来的(Struts的作者是JSF规范的主要制定者),来的晚,但技术及理念上要比Struts先进(即使是Struts2还是摆脱不了form驱动,UI没有组件化的问题),所以,JSF比例会逐渐提高. Spring MVC大部分情况只是被用做Controller.
Spring MVC没说要替代Struts，在我们公司的Appfuse中是因为MVC的弱化，和用了极精简配置，就不高兴再换了，因为在我们的方案里Controler里面代码非常少。 我认为JSF出现的太晚了，如果他能和Tapestry差不多同时出现，就不会像现在这样推广缓慢了。你也不要认为客户端的框架就不算组件化了。 引用 至于Ext,Dojo这一类基于Javascript的架构,会有一部分系统,比如那些有很高用户体验要求,操作复杂灵活的,但功能相对较少系统会采用. 但在大型的管理信息系统中采用的比例不会太高,这样的系统最终还是会选择开发效率高,易于维护,基于标准的技术,比如JSF, Struts.
SAP算大型管理信息系统么？他们马上就要上Flex了，开发效率高么？易于维护么？标准都是慢慢形成的，想想3年前的Hibernate吧。 引用 历史原因,公司里有三个产品,其中一个是JSF做的,其他两个是"历史沉淀"的杂牌军.
后来公司里需要做一个整合,把三个系统集中到一个portal服务器,由portal提供更好的用户体验. jsf可以不用做任何改动,只要在portal容器中配置对应的portlet就OK了.那些历史沉淀就傻了.没有任何褒贬的意思,只是一次经历.感觉标准还是非常好的东西. 你们公司走跟着这些大厂商走，这是当然的啦，咋不说你用微软的更方便呢。 个人愚见，portlet本身也是历史产物，现在眼光看也是个大忽悠，和EJB一样。 引用 还有关于权限验证的经历,一直觉得JAAS巨麻烦.快速应用开发,还不如自己写ifelse来的快.是的,ifelse贪图一时快乐,很有效果.就像楼主所说的,拿个文本写个html就马上能看到效果.但是产品继续做,继续维护和升级,继续和更多的外部产品整合,那些快捷的方案都会疯狂了.
有很多现成的框架可用，不用自己开发的。 引用 EXTJS是个很好的东西,他的API也很优雅,但是他绝对不是展示层的解决方案,注意我所说的是解决方案.用它写桌面浏览器的的portal也很酷,也可以用它在jsf输出的添加一些更好的用户体验(但是我更愿意采用DOJO),或是写几百行的javascript,给浏览器中的html添加一些很酷的效果.但是这些都只能是pc浏览器,而在手持设备上,就不能采用这种方案了,而jsf则可以继续用.
都讨论到手持设备上，厉害。你告诉我哪家方案手持设备用的时候JSF的方案并成功实施的。 引用 假如本身带着挑刺的观点去看一个东西,会发现,它是越来越讨厌,而忽略了他的迷人之处.
没说JSF不迷人，出来的太晚，推广的太慢，当年优秀的架构现在已不再优秀。以目前的眼光来看就是不再优秀了。 |
| 返回顶楼 | |
|
发表时间：2008-04-19
引用 除了Myface,每一个Java开发人员都已经安装了以上其他内容,从做Java开发第一天开始,你觉的这个哪里不正常了?
安装正常 但是我开发页面却要我把后台的东西都启动 都运行 这个正常吗? 我机器里安装了很多软件 但是我做一件事时 一般只打开和这件事相关的软件 能少开就少开 开发前台页面也是一样 我一般只用一个文本编辑器 必要的时候也许会启动一个小型的httpserver. 随时编辑 随时调试 随时预览 无需编译 无需部署 这样不好吗? 不要质疑我不懂得j2ee eclipse jsf. 我接触这些也有很长时间了 (jsf不长 但是我一直觉得他就是 tag servlet filter 的加强版) 其他的我也不回你了 回起来太累 如果有机会也许当面讨论 更合适 只是不知道到时候会不会因为意见不合动起手来 呵呵. 不管我俩观点怎样不同 但是有一点我很感动: 你是很认真的和我在讨论问题 否则你也不会写那么多字来回复我 谢谢你的认真. |
| 返回顶楼 | |
|
发表时间：2008-04-19
fangshun 写道 虽然自定义组件不好做，但是我的第二个项目，已经复用了很多第一个项目写的验证组件，转换组件，并且还在基础上不断完善，在第二个项目上又加入了一些有效的，特定方式的显示组件，也可以应用在以后的项目中，逐渐形成了一套自有风格的开发实践，很不错，而且代码很容易重构，变得极度精炼！
对于jsf的批评仍在进行中，但是懂得实践的人，已经逐渐尝到了基于jsf的组件化，标准化带来的开发优势，让不动手的人继续讨论它的优缺点吧。。。。。。。。。。。 组件化不是只有jsf才能做到的。至于标准化么，这个就见仁见智了。 |
| 返回顶楼 | |
|
发表时间：2008-04-19
lcllcl987 写道 UI层应该是在后台系统不变的情况下可切换的 fins 的眼光太狭隘。 fins狭隘到只有在游览器上运行的东东才是b， 在容器中， 哪怕是web容器中运行的就是s了。 但是如果把眼光放高点，也就是更广义的来看， 对于一个J2EE应用来说 UI层，应该是在web容器中运行的web框架， 比如JSF， structs等。 fins兄的眼光仅仅局限于web框架， 并且在web框架内部还要再继续划分一个所谓的B层， S层， 产生这样的谬论就不奇怪了。 那么你的眼光何尝不是局限于j2ee框架呢。 ui层可切换，那么后台可不可以换？ 还有，为什么一定要web“容器”？ 我们知道jsf的用意就是要去掉b/s划分。问题是这个划分是先天而成的，并不是fins划分出来的。所以质疑也是很好理解的。 且fins并没有说要在web框架里分b和s，fins的意思我认为是指他理想的Web框架是基于b/s解耦的架构。 |
| 返回顶楼 | |
