|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-04-27
leebai 写道 hax 写道 你的设计比我想象的更接近我理想中的方式，呵呵。而且我觉得你的设计其实离HTML组件方式很接近啊。 过奖，一切都还在探索中。 如果新的 HTML Specification 能包含treeview、listview、grid。。。等大粒度组件，web UI模式之争其实没有任何悬念，甚至RIA都不是对手（flex/javafx等要达到HTML/CSS同等的表达能力几乎是不可完成的任务，如果达到了，就是另外一个浏览器引擎了），虽然多媒体及图形方面RIA将会保持自己的价值。 在HTML升级之前，我认为最好的办法是以现有的，形式最接近的HTML元素为骨架，组合其他合适的HTML元素,通过扩充骨架HTML元素的属性、方法、事件，来构造大粒度的UI组件。目前的7wx组件已经很老了，新版本将会融合近来的一些想法，应该会有比较大的更新。 这个是关键中的关键，很有可能最后文字方面大家都差不多，但是多媒体和图形有可能就是能主导未来方向的，好比DOS到windows的过程，文字mud到图形网游，2D游戏到3D游戏的大变革。就看这个拐点何时到来，到时候又会先开始口水仗。 除了上述的大方向外，目前浏览器存在主要问题还有“JS虚拟机”的问题，解释执行实在没有必要，太低效了。 |
| 返回顶楼 | |
|
发表时间：2008-04-27
to achun:
|
| 返回顶楼 | |
|
发表时间：2008-04-27
icewubin 写道 。。。 除了上述的大方向外，目前浏览器存在主要问题还有“JS虚拟机”的问题，解释执行实在没有必要，太低效了。 呵呵，我倒没感觉js性能有问题（也许是因为喜欢用数组的原因吧:-)），现在的机器都和。。贼。。一样快，一个HTML再复杂，代码也多不到哪儿去，要做的工作也多不到哪儿去，怎么会有性能问题呢，除非使用不当。 |
| 返回顶楼 | |
|
发表时间：2008-04-27
leebai 写道
to achun:
可实际使用的时候是否过度使用，这个是可以控制的呀，js模板也可以不过度的使用呀！ 对于万能改锥太昂贵，可靠性来说，这个我不好说，毕竟我一直在研究这个，可能我觉得成本低，不昂贵，别人就不一定认同了。 不过我的方案，现在正在用，前台做html了同事只需要安心做html,css其他的什么都不用管，她觉得很安逸。 数据怎么来的，页面怎么装上去的，她几乎不用管 （其实页面上的变量和模板里的流程控制就是她写的，她对JS也是入门级的，很简单，都是标准的js语法，无外呼if,for）， 等项目做完了，有时间我会仔细根她说说的， 当然了目前这个方案还有些应用上的问题解决的不是很好，解决的方法还不优美，不过我相信随着深入的研究，最终会安逸和优美的。 |
| 返回顶楼 | |
|
发表时间：2008-04-27
leebai 写道 icewubin 写道 。。。 除了上述的大方向外，目前浏览器存在主要问题还有“JS虚拟机”的问题，解释执行实在没有必要，太低效了。 呵呵，我倒没感觉js性能有问题（也许是因为喜欢用数组的原因吧:-)），现在的机器都和。。贼。。一样快，一个HTML再复杂，代码也多不到哪儿去，要做的工作也多不到哪儿去，怎么会有性能问题呢，除非使用不当。 主要是指图像显示上的各种效果，图形显示的像素级控制如EXT，具体效果比如拖动一个框并实时显示，性能的需求是无止尽的，当然前提是需求中需要这些效果。 |
| 返回顶楼 | |
|
发表时间：2008-04-27
to leebai:
至于你举的例子，实际的需求比这个复杂的多。 举个新闻录入的例子,新闻有这个特点： 有些新闻很长，需要分页，在数据库里就是多条记录（可以放到不同的表里），比如有些软件使用的操作或者对一个复杂事情的跟进文章。 那我问你，录入这些有主记录和从记录的信息的时候，页面上是什么样一个布局，页面需要不停的刷新吗？ 如果要不停刷新，那我问你，如果你不是信息的录入人员而是网站信息的审核人员这样不停的刷新页面，你烦不烦， 每次刷完了之后为了能更好的操作也许，还要附上几十条最新的待审核信息的条目，以备继续的审核操作。 所以我觉得这个需求是有的。 就算为了搜索引擎，为了点击量客户浏览的时候你可以不停刷新，但是你内部自己用呢？ 自己就不是客户了么？ |
| 返回顶楼 | |
|
发表时间：2008-04-27
achun 写道 to leebai:
至于你举的例子，实际的需求比这个复杂的多。 举个新闻录入的例子,新闻有这个特点： 有些新闻很长，需要分页，在数据库里就是多条记录（可以放到不同的表里），比如有些软件使用的操作或者对一个复杂事情的跟进文章。 那我问你，录入这些有主记录和从记录的信息的时候，页面上是什么样一个布局，页面需要不停的刷新吗？ 如果要不停刷新，那我问你，如果你不是信息的录入人员而是网站信息的审核人员这样不停的刷新页面，你烦不烦， 每次刷完了之后为了能更好的操作也许，还要附上几十条最新的待审核信息的条目，以备继续的审核操作。 所以我觉得这个需求是有的。 就算为了搜索引擎，为了点击量客户浏览的时候你可以不停刷新，但是你内部自己用呢？ 自己就不是客户了么？ 对呀，如果不是为了点击量，不停刷新太消耗服务端资源了吧。 |
| 返回顶楼 | |
|
发表时间：2008-04-27
初步看了achun的jct，不是很看好。看上去jct比较接近传统模板，只是放到了前端。希望能看到jct更多的文档。
|
| 返回顶楼 | |
|
发表时间：2008-04-27
leebai 写道 如果新的 HTML Specification 能包含treeview、listview、grid。。。等大粒度组件，web UI模式之争其实没有任何悬念，甚至RIA都不是对手（flex/javafx等要达到HTML/CSS同等的表达能力几乎是不可完成的任务，如果达到了，就是另外一个浏览器引擎了），虽然多媒体及图形方面RIA将会保持自己的价值。 在HTML升级之前，我认为最好的办法是以现有的，形式最接近的HTML元素为骨架，组合其他合适的HTML元素,通过扩充骨架HTML元素的属性、方法、事件，来构造大粒度的UI组件。目前的7wx组件已经很老了，新版本将会融合近来的一些想法，应该会有比较大的更新。 非常赞同。实际上我觉得有了HTML5，基本上客户端模板就没有用武之地了。所以还不如做一个框架来在早期浏览器上实现HTML5。 |
| 返回顶楼 | |
|
发表时间：2008-04-27
leebai 写道
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文件越滚越大。“页面动态性。。。”那段没看明白，能否具体点？
虽然我目前对服务端组件框架更感兴趣，但也和乐于参与基于JS + HTML的客户端组件框架的讨论。因为采用何种框架完全取决于当前公司的技术导向，开发人员技能差异性，技术系好，成本和其他很多因素组成 也一条一条来讨论: 1. 对于一个成熟的JS框架，屏蔽低层的JS接口是很有必要的。JS的固有特性导致大部分开发人员很难开发出强壮的JS代码，包括是否有重复代码，是否跨浏览器，是否足够的灵活，能否做到js代码复用。客户端组件升级后，能否兼容先前的JS代码等等。所以，提供封装的APIs在我看来是一定要的 ，而且越抽象越好
2. 废弃传统意义上的Action层应该是以后的发展方向。因为Action无非是完成一些数据输入输出，动态导航之类的功能。所以假如你的框架还要发展，我觉得很必要考 虑一下把这层去掉
3. 客户端框架的的最重要特性就是必须要提供丰富的UI组件，组件内部可以相对复杂（不管采用JS template技术还是其他诸如HTML Template技术），但对外暴露的接口必须简洁
4. 用window.open MS感觉有点粗，即使你开放一个封装过的JS接口用来导航，也可能遇到一些动态导航的功能无法实现。假如你将Action层废弃，那么页面流这个概念需要加强
5. 暂时不讨论了
6. 不使用外部配置未免也有点太极端了，你的代码里包含了很多hard-coding的包名，方法名。预示着你的业务方法不支持重构，替换（不修改源代码）
另外，我很久以前建了一个相关的圈子和M群，有讨论意愿的朋友可以站内短信我 |
| 返回顶楼 | |
