该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2008-04-27
to taelons: 同意“Server business”中,business logic层不能直接暴露给客户端调用(js其实也不可能直接调用Java),你说的那个Fasade层,我原先也将其称作是Controler,但这样容易与MVC的概念混淆,所以现在倾向于这样表述: Ajax +“Server business”应用,就是View + Model应用,不存在Controler 而你说的那个Fasade层,其实大有文章,远比MVC的Controler内容丰富,本质上就是V/M框架,虽然7wxAop框架已经实现了V/M之间的很多控制,目前我还没找到合适的词来表达它,这方面可以深入探讨。 至于你说的“10个下拉框”个例,完全可以不依赖"Server Pages"技术:如果10个字典之间是独立的,则一次Ajax请求返回10字典数据既可。如果10个字典之间是联动的,在新建初始化时,只获取第一个字典;在更新初始化时,根据各字典的当前值一次性获取各字典的相应字典数据;初始化后在用户改变选择时动态加载下级字典。多级联动的另一个替代输入方式是树型组件,后者很多时候更灵活。
|
|
返回顶楼 | |
发表时间:2008-04-27
我大致看了下楼主自己开发的web框架,可以说是典型的JavaScript based的web框架。与几年前在市场上做的比较好的dorado类似。典型的特征是在客户端有一套相对比较丰富的JS UI组件和DataBinding机制
首先肯定一下楼主的框架,XJawa具备以上特征,应该说也确实能够实现一定范围内的快速开发。但单纯从技术上看Xjawa,我觉得还有几点值得探讨 1. 客户端的对象类型都是Javascript数组 (是否意味着在客户端模型的基本仍然停留在JavaScript低层语言级别,开发人员还需要掌握JavaScript语法)。另外,这套框架应该开放了大量的JS接口,这套接口学习的成本不低。所谓几个小时的培训恐怕~~ 2. 从该框架在服务端需要编写WebActions的子类可以看出,离所谓的纯粹的B和S还有点距离(WebActions子类完全不是业务方法,方法参数居然还是HttpServletRequest),这个比较好的实现楼主可参考DWR和Seam的实现 3. 楼主自行开发了大量的UI组件,这些组件应该是纯粹的JS控件。JS控件的缺点就是随着需求增加,控件的复杂度不断提高,最终可能会使得控件难以发展和维护 4. XJawa是否属于one page one application?如果不是,现在如何处理页面的navigation? 5. 其他问题,客户端的性能,是否延迟加载等等 6. 其他的由于业务复杂度导致的问题(多是导致页面动态性,比如通过某种复杂的条件导致页面大面积动态变化或替换XJawa是否能胜任)? 从楼主实现的框架和帖子来看,有少许对服务端技术的偏见。这点我也可以理解。我的建议是多比较比较客户端技术和服务端技术在整体和局部上的细节差异和优缺点,是不是真的如自己想象的那样。 比如楼主一再强调的 引用 在正真的B-UI应用中,Browser自己负责界面构造和界面跳转,Server只负责提供business logic 访问,也就是说Server上根本就不需要S-UI的Web层(虽然还是HTTP访问),没有所谓的Controler,也就是说MVC不再是真理,Spring MVC/Struts之类的Web层框架完全没有必要。
其实在你的框架里并没有真正实现,而目前服务端技术其实已经完好的实现了.从我以往的经验,不要过分将自己东西绑死在某一种方式或者技术上可能更有利于框架的发展 |
|
返回顶楼 | |
发表时间:2008-04-27
JJYAO 写道 我大致看了下楼主自己开发的web框架,可以说是典型的JavaScript based的web框架。与几年前在市场上做的比较好的dorado类似。典型的特征是在客户端有一套相对比较丰富的JS UI组件和DataBinding机制
首先肯定一下楼主的框架,XJawa具备以上特征,应该说也确实能够实现一定范围内的快速开发。但单纯从技术上看Xjawa,我觉得还有几点值得探讨 1. 客户端的对象类型都是Javascript数组 (是否意味着在客户端模型的基本仍然停留在JavaScript低层语言级别,开发人员还需要掌握JavaScript语法)。另外,这套框架应该开放了大量的JS接口,这套接口学习的成本不低。所谓几个小时的培训恐怕~~ 2. 从该框架在服务端需要编写WebActions的子类可以看出,离所谓的纯粹的B和S还有点距离(WebActions子类完全不是业务方法,方法参数居然还是HttpServletRequest),这个比较好的实现楼主可参考DWR和Seam的实现 3. 楼主自行开发了大量的UI组件,这些组件应该是纯粹的JS控件。JS控件的缺点就是随着需求增加,控件的复杂度不断提高,最终可能会使得控件难以发展和维护 4. XJawa是否属于one page one application?如果不是,现在如何处理页面的navigation? 5. 其他问题,客户端的性能,是否延迟加载等等 6. 其他的由于业务复杂度导致的问题(多是导致页面动态性,比如通过某种复杂的条件导致页面大面积动态变化或替换XJawa是否能胜任)? 从楼主实现的框架和帖子来看,有少许对服务端技术的偏见。这点我也可以理解。我的建议是多比较比较客户端技术和服务端技术在整体和局部上的细节差异和优缺点,是不是真的如自己想象的那样。 比如楼主一再强调的 引用 在正真的B-UI应用中,Browser自己负责界面构造和界面跳转,Server只负责提供business logic 访问,也就是说Server上根本就不需要S-UI的Web层(虽然还是HTTP访问),没有所谓的Controler,也就是说MVC不再是真理,Spring MVC/Struts之类的Web层框架完全没有必要。
其实在你的框架里并没有真正实现,而目前服务端技术其实已经完好的实现了.从我以往的经验,不要过分将自己东西绑死在某一种方式或者技术上可能更有利于框架的发展 听起来非常不错,我会好好构想的。 目前为止在想调试的时候会不会效率低下的问题,因为数据都挤在一起。 还有就是数据先集中再各自分发,自己要搞一个规模不小的框架,第一感觉就是投入很大啊,又没有现成的比较成熟的框架能搞定这个“数据岛”模式的?或者是系统性的介绍有没有啊? |
|
返回顶楼 | |
发表时间:2008-04-27
JJYAO 写道
我大致看了下楼主自己开发的web框架,可以说是典型的JavaScript based的web框架。与几年前在市场上做的比较好的dorado类似。典型的特征是在客户端有一套相对比较丰富的JS UI组件和DataBinding机制
首先肯定一下楼主的框架,XJawa具备以上特征,应该说也确实能够实现一定范围内的快速开发。但单纯从技术上看Xjawa,我觉得还有几点值得探讨 1. 客户端的对象类型都是Javascript数组 (是否意味着在客户端模型的基本仍然停留在JavaScript低层语言级别,开发人员还需要掌握JavaScript语法)。另外,这套框架应该开放了大量的JS接口,这套接口学习的成本不低。所谓几个小时的培训恐怕~~ 2. 从该框架在服务端需要编写WebActions的子类可以看出,离所谓的纯粹的B和S还有点距离(WebActions子类完全不是业务方法,方法参数居然还是HttpServletRequest),这个比较好的实现楼主可参考DWR和Seam的实现 3. 楼主自行开发了大量的UI组件,这些组件应该是纯粹的JS控件。JS控件的缺点就是随着需求增加,控件的复杂度不断提高,最终可能会使得控件难以发展和维护 4. XJawa是否属于one page one application?如果不是,现在如何处理页面的navigation? 5. 其他问题,客户端的性能,是否延迟加载等等 6. 其他的由于业务复杂度导致的问题(多是导致页面动态性,比如通过某种复杂的条件导致页面大面积动态变化或替换XJawa是否能胜任)? 从楼主实现的框架和帖子来看,有少许对服务端技术的偏见。这点我也可以理解。我的建议是多比较比较客户端技术和服务端技术在整体和局部上的细节差异和优缺点,是不是真的如自己想象的那样。 比如楼主一再强调的 引用
在正真的B-UI应用中,Browser自己负责界面构造和界面跳转,Server只负责提供business logic 访问,也就是说Server上根本就不需要S-UI的Web层(虽然还是HTTP访问),没有所谓的Controler,也就是说MVC不再是真理,Spring MVC/Struts之类的Web层框架完全没有必要。
其实在你的框架里并没有真正实现,而目前服务端技术其实已经完好的实现了.从我以往的经验,不要过分将自己东西绑死在某一种方式或者技术上可能更有利于框架的发展
不能在短时间内理解7wxAop不是你的问题,一方面大家对“Server business”模式还比较陌生,另外7wxAop的文档也欠缺,希望通过讨论我能把它说清楚。
7wxAop是一个精简的框架,客户端7wx封装的js代码大约是3000行,服务器端Aop封装的Java代码大约是8000多行,写最简洁的代码是我的编程原则,因此代码量可以看出工作份量:首先它是一个Web开发的总体框架,其次大头在“Server business”(Aop),“JS based UI”(7wx)部分相对简单,当然从重要性来说两者相当。相比Ajax无刷新机制、Ext/dorado的丰富UI组件,7wxAop的侧重点是“Server business”编程支持,7wx倒是可以被其他组件替换。
我确实不喜欢“Server Pages”用于业务应用,从servlet println() 到JSP、Tag、velocity、jsf。。。因为对强交互的业务应用来说,这种结构不合理。但对于CMS/BBS/BLOG/WIKI/社区/圈子...等等以信息服务为主的应用(不含这些东西的后台管理系统)来说,“Server Pages”是必然之选,“Server business”反而不适合,这一点我看得很清楚,基于7wxAop开发的Kontent CMS,其实信息服务部分就是“Server Pages”技术。
关于你提的几点探讨,还是一条一条来:
1、我个人喜欢用数组,我想老一点的程序员(用过Apple BASIC,或更老的)都喜欢用数组。 能用数组简单完整的任务,为什么非要用Iterator或各种Collection结构?越简单的数据结构,系统开销越小,运行越快,越不容易有内存泄漏等难以排查的Bug。尤其是对于一个HTML页,其应用代码再复杂,能复杂到哪儿去,非得要用高端对象代码来提高程序可读性? 另外我说过使用7wxAop需要一定的 js 基础(如主题所说,我认为不会JS的Web开发者是半拉子开发者),js的培训不算框架的培训,7wx远没有Ext复杂,所暴露的接口并不多,即便通读其3000多行代码,也用不了1天时间。所以7wxAop的学习开销你完全不用担心。
2、你的意思我明白:主流的分层模型教导我们,不要将Web层的东西传递到业务层,WebActions既然用了HttpServletRequest,WebActions就不是业务层了。我的观点是,如果你有独立的业务层(比如EJB),就把WebActions当成Web层好了;否则,7wxAop建议在WebActions中实现所有的Model功能,那么HttpServletRequest是否玷污了Model?如果存在Web层,则是;但7wxAop中不存在Web层,7wxAop的“Server Business”模式本身并不依赖于Web层的Servlet API,甚至也不需要HTTP协议 的 full implementation ,这里使用HttpServletRequest而不是诸如ActionRequest的对象作为WebAction的参数,只是为了实现方便,也许在下一个版本的7wxAop,你就会看到一个ActionRequest(现有框架代码中的org.xjawa.system.DeepRequest类就是用于这个目的,只不过没实现,该类目前在框架中悬空没用)。所以,你说的“离所谓的纯粹的B和S还有点距离”是对的;另一方面,如果克服一下主流的分层模型教导我们的“洁癖”,以及根深根深蒂固的Web层观念,Model层使用一下HttpServletRequest也不是什么原则性的问题。
3、你的说法“政治上正确”。7wx的组件其实不是很多,和Ext等强调OO的UI组件不同,7wx组件采用HTML模版来作为组件显示元素,扩张相对容易。
4、不是。7wx在框架内部使用最简单的window.open跳转页面(不鼓励也不反对用户代码直接使用window.open)。
5、7wx很快,界面响应比Ext快的多。下载的系统已经有很多应用功能,你自己可以体会。分页是“延迟加载”,性能自己体会,7wx翻页允许最终用户自己改变每页行数,在确实需要浏览很多条目的情况下,比“预先加载”方式更有效。
6、使用7wxAop,业务复杂度的增长和系统复杂度的增长是线性的:在前端,增加业务只是HTML页面;在后端增加业务只是增加WebActions,不会有哪个XML文件或Java文件越滚越大。“页面动态性。。。”那段没看明白,能否具体点?
|
|
返回顶楼 | |
发表时间:2008-04-27
探讨很有意思,不知道楼上几位都在什么地方,如果能找机会聚在一起互相介绍一下各自的框架和经验,就更好了。
|
|
返回顶楼 | |
发表时间:2008-04-27
hax 写道 探讨很有意思,不知道楼上几位都在什么地方,如果能找机会聚在一起互相介绍一下各自的框架和经验,就更好了。
确实有直接交流的必要,好像你们上海和阿拉北京的人相对多些,其他地区的网友比较散。 |
|
返回顶楼 | |
发表时间:2008-04-27
leebai 写道 hax 写道 探讨很有意思,不知道楼上几位都在什么地方,如果能找机会聚在一起互相介绍一下各自的框架和经验,就更好了。
确实有直接交流的必要,好像你们上海和阿拉北京的人相对多些,其他地区的网友比较散。 我是上海的,现在确实碰到一些问题,无法通过现有交流渠道听听别人的见解,我的部门经理现在不管具体的技术实现了,技术细节无法找人论证,又不能动不动就拿实际项目做实验,这个问题越来越严重了。 |
|
返回顶楼 | |
发表时间:2008-04-27
leebai 写道 其实你这jCT中的“存储”型模板,完全可以被7WX框架借用(7WX中也有类似的东西,只是功能没jCT强)。Browser UI模型的“局部界面更新”,除了主流的“组件方式”外,确实还应该包含“模版方式”。
虽然我没有看过jCT和7WX,不过先放个空炮。上次jindw说他要搞客户端模板,我就跟他聊说客户端模板没啥前途,或者说存在一些与服务器端模板类似的问题无法解决。 模板(template)的主要问题是它是一种代码生成方式,因此与最终运行时模型是不匹配的。因此模板虽然有利于方便、安全的生成重复的代码,但是编写运行时脚本时的复杂度却大大上升了。我个人认为native的B端组件(data binding)才是王道,呵呵。 |
|
返回顶楼 | |
发表时间:2008-04-27
to icewubin:
有需要的话可以给我发站内短信,不过事先声明: 流行的Struts,Spring,Hibernate,JSF,XMLHttpRequest,prototype,Ext,IOC,Tag lib,jquery,rest,EJB,SOA,dojo(估计可以列出50个名词)。。。我都不会用,请不要问,呵呵; 我只会:Java,Servlet API,JSP懂一点,SQL/JDBC,HTTP协议, HTML/CSS,DHTML/DOM,Javascript这么几个基本的东西。底层的东西基本上难不倒我。 |
|
返回顶楼 | |
发表时间:2008-04-27
hax 写道 leebai 写道 其实你这jCT中的“存储”型模板,完全可以被7WX框架借用(7WX中也有类似的东西,只是功能没jCT强)。Browser UI模型的“局部界面更新”,除了主流的“组件方式”外,确实还应该包含“模版方式”。
虽然我没有看过jCT和7WX,不过先放个空炮。上次jindw说他要搞客户端模板,我就跟他聊说客户端模板没啥前途,或者说存在一些与服务器端模板类似的问题无法解决。 模板(template)的主要问题是它是一种代码生成方式,因此与最终运行时模型是不匹配的。因此模板虽然有利于方便、安全的生成重复的代码,但是编写运行时脚本时的复杂度却大大上升了。我个人认为native的B端组件(data binding)才是王道,呵呵。 支持。 |
|
返回顶楼 | |