从JSF和Ext看WebUI开发--给对JavaScript 有恐惧感的朋友
关键字: jsf ext话题由来:http://www.javaeye.com/post/523520?page=1
把其中我的观点整理出来:
|
100%支持fins!!! B端和S端彻底分开,分别有自己的框架,“UI层与系统其他层面的东西的唯一联系应该是"数据" ,UI层应该是在后台系统不变的情况下可切换的”,这种架构策略完全可行,而且实际代码上也比JSF/asp.net等“server page”变种优雅,本人已经在N个项目中实践过: http://www.deepsoft.com.cn/ext-aop/demo.html ==================================== 。。。正如我前面提到的,不理解fins的人大多是思想被“server pages”禁锢者,总认为浏览器只能负责 html render,其他一切都应该在服务器上完成,就如IT业早期的主机-字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端,完全忽略和闲置了目前运行浏览器pc的强大计算功能。 。。。在一个server和UI无关的模式下(下面称为“server business”,与“server pages”对应),server只是一个business logic server(只接受UI请求改变或查询系统的state),大致相当于砍掉了J2EE的Web层,Lightweight是肯定的了,至于Performance,除了节省处理 。。。“server business”模式(SB)与“server pages”模式(SP)本质上是不同的,SP下的'presentation layer'概念并不适合SB模式。 。。。将ajax单纯地视为transition technology本身也没什么错,虽然Ext等前端组件已经超越了这一概念。用Javascript framework称呼基于浏览器的“全功能UI Layer"并不适当,后者 = HTML + DHTML(DOM) + JS,JS只是一个粘合剂,Ext等前端组件本质上只是扩展了HTML Element,假设HTML 6.0包含了功能强大的TreeView、ListView(GRID)等通用UI组件,则JS将回归为单纯的DHTML API操纵语言。 至于RIA(javaFx or Flex),我认为它是侧重多媒体表现的“全功能UI Layer"的等价物,它的发展前景取决于厂商对它的定位,如果你认同RIA,就没有理由不认同“全功能UI Layer"的思路。 |
JSF:基于服务器端的UI模型,Ext:基于浏览器端的UI模型。
很多人质疑以JavaScript为中心的UI开发,其实是对html/JavaScript的恐惧。
1、 不要把《 HTML(含CSS) + DHTML(或DOM)API + JavaScript开发》 简单理解成 JavaScript 开发。很多人觉得“JavaScript”难以掌握,是因为他们混淆了JavaScript脚本语言本身和它所要操纵的API:其实JavaScript本 身 非常简单,但它所要操纵的API“非常复杂”,因为HTML(含CSS) + DHTML(或DOM)API所涉及的API对象、属性、方法、事件数量巨大,可以说和Win32 API,JDK API(不单是swing/awt)同一个数量级。
2、HTML(含CSS)作为UI的表达语言,其“潜在的”界面表达能力应该说远远超越任何已有高端UI组件库(asp.net,jsf,Ext...),因为它们本 身 都是基于HTML(含CSS)开发的,要想完整地(还不含绘图)、无障碍表达WebUI,掌握HTML(含CSS)及其API--DHTML(或DOM)是必由之路。
3、所有高端UI组件库的设计思想都是提高组件粒度,以掩盖HTML(含css)的复杂性。不同在于,服务器端UI组件(asp.net,jsf)试图“彻底”掩盖,它们排斥直接使用HTML(含css),并且操纵UI组件的API面向后端语言(C#,VB,java);而浏览器端UI组件(Ext等)是“开放性的”封装,允许直接操作HTML(含css),操纵UI组件的API面向javascript。
4、服务器端UI组件的使用者,一般不太关心组件的具体实现,而且使用中也缺乏HTML+JS的训练,当组件功能满足不了要求时,自己扩展组件的难度很大,也就时说使用组件和开发组件之间存在巨大鸿沟。而浏览器端UI组件的使用者,一般会大致了解组件的实现,使用中频繁接触HTML,JS操纵能力也得到训练,因此他们会比较自然地形成组件改造扩展能力,使用组件和扩展组件之间得学习曲线是平滑的。
5、因此,从开发人员自身职业发展的角度看,要想成为无障碍的Web开发者,使用浏览器端UI组件模式应该是更好的选择。
作为Web开发者,必须热情拥抱HTML(css)和javascript,否则只能是半拉子开发人员。
评论
所谓,b/s就是一个B 一个S
所谓C/S就是一个C 一个S
都是分开的~
从理想效果来看,当然降低耦合最好,包括开发人员职能/各种脚本语言/结构清晰等等
但是,到底哪种好,是由项目说了算~
说JSF/ASPX不好,可是他带来的快捷是不可否认的,况且,你所认为的复杂/乱,都是在他的管理之下,所以,这些你不用操心。
况且,JSF+自己定义的UI框架,也不是不可以结合,取各自的优点不好么?
如果他不能满足你的需要,那当然就用别的方法来实现。
大家在说明自己的追求的时候,都忽略了一点,我们的追求是建立在每一个项目基础上的
哪种更合适用哪种~
不过,各位给出的连接,确实很有意思~
学习ing
感觉很受启发
结论拟先研究-->再试用后,再发表:)
By Rushio Wang.
谢谢关注。
本人对技术的兴趣很没常性,经常很长时间不写不看任何代码,也不看技术文章,不上技术论坛,希望关注该框架的朋友要有耐心,不要期望从我这里得到多好的支持,最好自己通读框架代码,理解后想做什么就做什么。
感觉很受启发
结论拟先研究-->再试用后,再发表:)
By Rushio Wang.
一直用的是java
在这两年里面,从最基础的mode1 到 jsp+servlet+javabean(mode2) 再到 struts,spring,hibernate
我最深的感受就是越到最后 月要把以前学习的东西抛弃掉,
比方说 之前经常要写一些html css javascript 到最后 好像jsf 和struts 就不这么写javascript乐
经常会有人提到 ssh开发 我一直没有感觉到这个所谓的主流框架有多么的好!
对于当前主流框架来说,我更喜欢mod2更喜欢用jsp+javabean+servelt开发,
表现层我宁愿用html+css+javascript!
呵呵 这个是我一个新手的心声!
问题是你在公司里不是单干的,你要和别人合作,你要服从架构师的规范,要和团队保持风格一致。
恩,是啊,很多用过之后感觉都不如自己写个类来的方便,特殊需求决定了特殊的解决方案!
一直用的是java
在这两年里面,从最基础的mode1 到 jsp+servlet+javabean(mode2) 再到 struts,spring,hibernate
我最深的感受就是越到最后 月要把以前学习的东西抛弃掉,
比方说 之前经常要写一些html css javascript 到最后 好像jsf 和struts 就不这么写javascript乐
经常会有人提到 ssh开发 我一直没有感觉到这个所谓的主流框架有多么的好!
对于当前主流框架来说,我更喜欢mod2更喜欢用jsp+javabean+servelt开发,
表现层我宁愿用html+css+javascript!
呵呵 这个是我一个新手的心声!
我多年的编程习惯是,自己能做的事,尽可能自己做:除了工作量太大的web服务器、数据库服务器、全文检索引擎,以及一些绝对可靠的工具,系统中涉及的绝大多数东西都自己实现,比如web框架、持久化模型、前端UI组件、ajax通讯组件、文件上传组件、HTMLEditor、log策略。。。这些东西其实都不是很难,第一次用比直接使用现成的东西会多花点时间,但时间长了自己做的东西在使用效率、可整合性、可调试性、可扩展性等方面都会有明显优势。
感觉观点有点偏激,并不是什么都是自己实现的才是最好,有些开源控件已经可以满足需求,而且扩展性也不错,大部分项目的开发时间都是很紧的,很少有人在项目开发过程中发明重复的轮子,当然自己可以做封装以便以后的项目使用,但是任何学习都是有成本的,你封装的框架要想让别人学习,跟学习struts2,jsf 一样需要时间,而且越通用的框架,必然内部越复杂,这是为什么国内很多项目的开发一直使用struts 1.x的原因。
GWT还是属于服务端生成的,怎么能让双方都接受?
如果都能接受,干嘛还出个GWT-EXT。
也就是说,你绑在一棵树上了。如果不出GWT-EXT,难道你自己封装么?
很多优秀客户段框架的选择权就放弃或者部分放弃了。
对于个人还好,对于一个团队,对一个技术的直接或间接投入的人力成本是很大的。
从一个技术管理人员的角度来看某个技术的话,一般都是从各种风险和成本入手,找平衡点。
JS+DHTML+CSS 和 pl/sql + trigger 多像。
哈,有反例啊,ORM我就不接受,哪天单发个帖子抨击ORM,先转贴一个我在xjawa网上的简单评论:。
明白了,怪不得前面吵的这么厉害,原来大家路线不同啊
不要太相信大厂商,我们做过6年IBM的ISV,知道大厂商的东西未必都事好东西;而且从软件产业发展的历史看,失败的技术远多于成功的技术。
这东西不是说盲目相信不相信的问题 判断当然要靠自己。我想你也看到了,这地方的有些程序员是非常幼稚的,动不动就猜测XXX商业利益驱动的结果,什么技术派系斗争啦,某某高管生孩子啦(这个是我编的)。好像大厂商的东西就是过家家弄出来的玩物一样。大厂商出的东西你可以评论,也可以不用,但是不用的理由不能太可笑,有些原则性错误(比如说试图永久性消灭HTML和JS,事实上HMTL+CSS+JS这种模式很受MS和SUN的认可,连桌面软件都在借鉴这种结构)根本就不可能有人犯。
我看到的是,很多优秀的技术在无知的人手中被浪费,又因为这些失败而被盲目地批判。大多数技术都处于两个极端,要么被疯狂的追捧(就像现在的Ext),要么被疯狂的批判。到最后技术本身究竟是怎么回事都没多少人知道了,剩下的全是观点。初学者则往往被这些观点左右,形成更加盲目的群体。
JS+DHTML+CSS 和 pl/sql + trigger 多像。
哈,有反例啊,ORM我就不接受,哪天单发个帖子抨击ORM,先转贴一个我在xjawa网上的简单评论:。
不看文档 也不认真了解(能同时找到.NET的文档 JSF的文档 ECMA262 XHTML的XSD和文档的同学举下手 全看过的也举下手)
其实麻烦就在某些人根本不知道什么叫组件模型 在一些显然没边的问题上胡扯 所以根本没法说。我也不是开培训班的 没兴趣普及软件基本理论。没学过计算机或者上学期间没好好学的同学就不要在这里不懂装懂了。
组件模型碍着标签封闭什么事了,某人公司的.net程序员垃圾,跟组件模型有何关系?所以我说MS和SUN这种做技术的公司,做出来的好多东西都被浪费了,不喜欢SUN但我也替SUN悲哀。无知很悲哀,但是被无知者当作无知更悲哀。
成天在社区对不了解的技术说三道四,什么商业利益、管理层分歧、技术派系,其实跟三姑六婆说家常里短没什么区别,是最没出息的程序员做的事。
不要太相信大厂商,我们做过6年IBM的ISV,知道大厂商的东西未必都事好东西;而且从软件产业发展的历史看,失败的技术远多于成功的技术。
很认同你说的:不要乱用框架。拼凑使用各种框架、工具确实是项目失控的重要原因之一:不能100%地把握框架和工具,有时就会被框架所困。
我多年的编程习惯是,自己能做的事,尽可能自己做:除了工作量太大的web服务器、数据库服务器、全文检索引擎,以及一些绝对可靠的工具,系统中涉及的绝大多数东西都自己实现,比如web框架、持久化模型、前端UI组件、ajax通讯组件、文件上传组件、HTMLEditor、log策略。。。这些东西其实都不是很难,第一次用比直接使用现成的东西会多花点时间,但时间长了自己做的东西在使用效率、可整合性、可调试性、可扩展性等方面都会有明显优势。
web框架和前端UI组件绝对是应该自己写的 其实主要原因是现在的框架太烂 但自己写的就算不如它们 也好控制得多 不论是优化、排错还是裁减
我自己没什么特别的观点 反正我自己什么都不用 只是有些明显的错误挑一挑而已
如果谈组件模型 决不是这种谈法
JE这个地方 初看到处都在讨论分析、架构和设计,其实进去帖子才知道 大多数都是些不知是什么的东西。
××的(留点口德)服务端组件模型,生成的代码那叫一个垃圾!
http://www.gs1cn.org/template/demoGDS.html
还少了一个</div>闭合标签,我们那个5年的.net程序员,2年多到现在愣是改不过来;项目里类似这种控件生成的垃圾代码到处都是,还跟新人侃这个框架、那个组件……多有经验啊——真让人替这些新人担忧;js组建更是到处抓,导致项目埋下n多地雷,我做了许多测试都心惊肉跳……;跟他说到这些还脸红鼻塞的……最是替那些个项目担忧了!
——不学也罢,脏了眼睛,时间也宝贵着呢。
http://www.gs1cn.org/template/demo.html
看看什么叫CSS+html过硬!什么叫语义网!那些打包好的××的(留点口德)服务端组件模型会明白吗?等着自己开发吧!
——js上也逼着自己开发zCool库,优雅而健壮的实现再辛苦都快乐(过段时间有机会贴上来献丑)——I love in it!!
我只是个做前端设计的,快30岁才入行,写js程序算是个八脚毛,
绝对希望和楼主这样的程序员搭档!
谢谢zbm2001兄认可。
很认同你说的:不要乱用框架。拼凑使用各种框架、工具确实是项目失控的重要原因之一:不能100%地把握框架和工具,有时就会被框架所困。
我多年的编程习惯是,自己能做的事,尽可能自己做:除了工作量太大的web服务器、数据库服务器、全文检索引擎,以及一些绝对可靠的工具,系统中涉及的绝大多数东西都自己实现,比如web框架、持久化模型、前端UI组件、ajax通讯组件、文件上传组件、HTMLEditor、log策略。。。这些东西其实都不是很难,第一次用比直接使用现成的东西会多花点时间,但时间长了自己做的东西在使用效率、可整合性、可调试性、可扩展性等方面都会有明显优势。
没有语义连机器都不会读!
以哲学观点 任何信息中都含有语义
这个地方我确实说的不恰当
不过我没兴趣跟你讨论哲学问题 我这里的语义显然指易于被人理解的语义
准确地再说一遍:
你为什么不挑CL生成的汇编代码语义的可理解程度差呢?
说的好啊!“aspx页面才是源码 语义只存在于源码中”
——我想这是一个绝佳的(原谅我用这个词)分歧点,到底是我们命令程序往我们编写的文档里插入或操作数据呢?还是让程序挟着我们的文档操作呢?
不知所云了
发表评论
提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则
- 浏览: 37462 次
- 性别:

- 来自: 北京

- 详细资料
搜索本博客
最近加入圈子
最新评论
-
从JSF和Ext看WebUI开发 ...
这有什么争论的~ 所谓,b/s就是一个B 一个S 所谓C/S就是一个C 一个S ...
-- by tonik -
从JSF和Ext看WebUI开发 ...
rushio 写道正在认真阅读http://www.xjawa.org/xjaw ...
-- by leebai -
从JSF和Ext看WebUI开发 ...
正在认真阅读http://www.xjawa.org/xjawa/kontent ...
-- by rushio -
从JSF和Ext看WebUI开发 ...
alger 写道解除了B/S开发已经两年了 一直用的是java 在这两年里面 ...
-- by icewubin -
从JSF和Ext看WebUI开发 ...
leebai 写道 很多年来,J2EE社区的各种时髦技术大多数也很荒唐。 ...
-- by jyfln1234






评论排行榜