|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-03-02
呵呵，你是说OPOA你不能接受，理由我能理解！
我本身也不主张OPOA，觉得有点过了，这种方式代码的维护和调试都不方便，所以我主张OPOF， 另外再在客户端建立一个与UI无关的全局静态的Application对象！实现方式就像我上面说的：通过一个100%*100%大小的框架页面！ |
| 返回顶楼 | |
|
发表时间：2006-12-05
one page one application!
调试与测试更方便，做到数据,样式，描述（展现），事件－－－>action--->逻辑,分离。 not :dojo.....object.innerHTML="<input>...</input>" 这使我想到了servlet的System.out.print("<html>") ; not :<script> function test1(){}</sceript> css: .table { ....... } one page one config :<Controls> <Control id="tableOfficerInfo" type="DataTable" dataset="dsOfficerInfo" maxRow="10" readOnly="true" height="280" width="100%"> <Column name="FLAG" label="" width="60" align="center"> <Events> <Event name="onRefresh">var personId=record.getValue("PERSON_ID"); dsRewards.moveFirst(); while (!dsRewards.isLast()) { finally { } </Event> </Control> 注意 红色标注，ajax数据源 page :仅仅只是<table id="tableOfficerInfo"/> 如果，数据,样式，描述（展现），事件，action，逻辑 impl one page ....两个字恐怖！ |
| 返回顶楼 | |
|
发表时间：2006-12-05
OPOA有它的适用场合，应用为主的系统合适一些，内容为主的不太合适.
DOJO追求的就是OPOA，第一次启动下载200k，启动慢的要死，客户哪里还有耐心，早等死了。 微软的ASP.NET 1.0, form postback, web form, 也是OPOA这一套, 搞了五年了, 用起来还是别扭, ASP.NET 2.0加的东西，都是为了摆脱OPOA。 引用 AJAX/AMOWA的兴起为我们开阔了很多视野。比起原来的web框架，这种OPOA的方式能够更快，减少更多的编码量，并提供更好的用户体验。当然，上文中提出的只是一个原型实现，如果尝试自行实现，可能更多的东西需要考虑，如安全，缓存，事件回调机制，内存管理等等。但这将是一个方向，一个可以提高开发体验与用户体验的方向。 这话前后矛盾，等把安全，缓存，事件回调机制，内存管理等等全加上了，看你是不是够更快，减少更多的编码量。提高用户体验的方法很多，DOJO第一次启动死慢死慢，可一点不提高用户体验。 我的观点还是要优先研究领域的问题，找到对这个领域问题最合适的解法，而不是纯粹追求OPOA。 |
| 返回顶楼 | |
|
发表时间：2006-12-08
box 写道 概念是简单，问题是接受程度以及代价。
坦白说我是不接受的，给我的感觉就是非要用windows自带的画图程序来画3D效果图， 我承认你做得出来，但是你不累我觉得也累。 有人说某一天windows自带画图程序会大幅度改进，所以我们要先摸索如何用现有windows画图程序来画3D图。 我觉得现在得OPOA也就是这么回事。 One Page和One Application 是个比较的老的概念了,我觉得可以接受,记着在哪看过一篇文章一个好的OPOA能减少50%的代码量 |
| 返回顶楼 | |
|
发表时间：2007-01-20
根据以前做Flex的经验，这思想是可以接受的，确实可以减少代码量。在公司一个项目中，它的首页有很多个Frame，loaded时间很慢长，我觉得用OPOA应该可以改善。
但话又说回来了，有时候把一个Web系统做得太Desktop了，它真的能提高软件的复用性吗？ |
| 返回顶楼 | |
|
发表时间：2007-01-21
偶原来做的MIS系统有点类似One Page, One Application.
 .页面数极少,只有登入页面,修改密码页面,还有登入以后的主页面.主页面上绑定了树控件,表单控件,按钮控件,以及下拉列表控件.这些控件都是公司UI人员基于HTC概念开发的.树数据源是后台传过来的XML,不同的表单对应不同的模板,模板做缓存处理.表单的数据也是XML.主页面有许多的脚本用来处理应用中各种各样的操作.
后台数据的组装和解析用dom4j,这个工作一般会在拦截器中做掉.另外在后台对于(HTC)控件也做了抽象,在需要用到这些控件的系统中,这些代码完全可以复用.系统开发工作量不大. 由于页面非常少,页面上的html标签也非常少(页面都是html文件),不用花经历在页面上.页面上需要调试的只是脚本. 系统用ajax,webwork(只用了xwork和拦截器),spring,hibernate,开发.在这种模式下开发,可以重用的代码非常多. |
| 返回顶楼 | |
