锁定老帖子 主题: 使用Dojo的痛苦经历
精华帖 (0) :: 良好帖 (0) :: 新手帖 (1) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-05-21
yiaduo能否介绍一下dojo如何做package的。
|
|
返回顶楼 | |
发表时间:2008-05-21
正在学dojo,确实感觉dojo对js代码的命名管理非常好的,不应该有作者那样的问题。
|
|
返回顶楼 | |
发表时间:2008-05-21
大部分的框架都是 "看上去很美"
主要原因是这些业余框架的作者水平太低 可能WebUI和AJAX写了几年 有点经验 不过对于大型程序组织 系统设计基本是小白状态 你看大公司的框架YUI MSF再烂 也不至于搞成楼主这种情况 |
|
返回顶楼 | |
发表时间:2008-05-21
如果楼主做的RIA的话,我想不应该有那么多的页面的吧?一般的RIA也就是几个页面,否则你总是载入页面怎么行?是不是架构有问题?
我现在也在用dojo 1.0做RIA,基本上只有一个页面,也就是初始载入慢一点(可以说我们会载入上百个js文件,本地大概10s左右),其他的都还好,包括性能都是可以接受的。另外我们想把载入js做成lazy load的方式,这样进一步提高初始速度。 至于命名冲突,这个在dojo应该管理的非常好了,跟java的package几乎等效,不明白LZ怎么会有冲突的问题,可能对dojo没吃透? 不过我也要承认Dojo有些东西确实考虑的很不周全,有很多bug,但是作为企业开发,你总不能指望一个开源框架把你的需要都做出来吧,总是要改点代码的吧? |
|
返回顶楼 | |
发表时间:2008-05-21
请教大家dojo的package的管理模式:)
|
|
返回顶楼 | |
发表时间:2008-05-21
dojo的渲染机制有没有改善方案,每个页面都渲染两次,特别是第二次,很慢的,几十控件就要近10秒钟,想想办法。
|
|
返回顶楼 | |
发表时间:2008-05-21
个人觉得dojo太麻烦了,要记很多"包"名和意义,如果有很好的开发工具支持可能就会好用了.
|
|
返回顶楼 | |
发表时间:2008-05-21
sp42 写道 dojo没ext那么多license问题。 SmartClient不知怎么样,使用LGPL的license。这不,就见到一个用户前来咨询ext-->SmartClient的情况(估计受license的影响): 引用 Is there any better way to migrate from Ext to SmartClient?
引用 For example, take the "Array Grid" Ext example source:
new Ext.grid.GridPanel -> isc.ListGrid.create columns -> fields stripeRows -> alternateRecordStyles Then in each field: id/dataIndex -> name renderer -> formatCellValue sortable -> canSort header -> title http://forums.smartclient.com/showthread.php?p=7615#post7615 Ext、SmartClient改变license,个人认为确实是基于商业利益而作出的调整。此前,SmartClient一直纯商业运作,Ext则在LGPL的“庇护”下快速成长(相信作者本人也没有预料到Ext发展如此之快),但各有各的烦恼。 SmartClient公司(确切说是Isomorphic)的客户一直不是很多,但该公司能坚持7、8年之久,估计还是赢利的。推出LGPL版本的产品,目的还是吸引更多客户,他们的商业策略是靠推销高端组件或定制服务来挣钱,想要使用LGPL实现自己的商业应用估计是没有希望的,只能玩玩而已,因为此版本的所包含的精简服务端组件不允许部署,见http://www.smartclient.com/product/smartLGPL.jsp。而且,所谓LGPL版本,在开放源代码方面也只是做个样子,因为SmartClient开放了基本组件的源代码,更基础的源代码还没有开放,即使开放也没有什么意义,原因是看惯了Prototype和Ext的源代码,读真正的SmartClient源码会让人疯掉的。 在SmartClient实际开发过程中,会遇到组件扩展或一些诡异问题,都会由于无法找到类似ext-all-debug.js那样的源代码让你放弃跟踪转而请求SmartClient帮助,要是遇到扩展或性能提升,估计只有买商业组件了。没有服务端的SmartClient,什么都做不了。 综上所述,推出LGPL协议的SmartClient,最终目的还是商业利益。 至于是否选择SmartClient,我觉得要综合考虑很多因素: 首先,选择框架不能基于道德评判。就像不应该因为“开源”盲目选择Ext一样,也不应该因为是商业一概排斥。更不能把所谓的不道德和背信(试想SmartClient的老用户看到开源版本,是否会像大批Ext的支持者一样批判SmartClient)作为选择框架的条件。 其次,适合的才是好的。对于专注商业应用而非技术本身的客户,采用SmartClient这类不透明的Ajax框架,做应用更加快速和专业。看到有人哭诉采用dojo导致的种种bug和版本不兼容,使用专业和组件化的库、购买专业的服务,不是更明智吗。当然前提是要有足够的money。 声明,根据我本人的实际经验,在Ajax框架中,SmartClient无论在效果、功能、标准化和扩展性上,都算得上是比较好的框架。至于性能,我还没有足够的经验和数据来证明。 无论如何,我觉得Ext中途改变license,还是不太“讲究”的。看GWT-Ext的作者如何说http://jroller.com/sjivan/entry/update_on_future_direction_of1。 The first is the ethical aspect of a company choosing to change licenses on a dime and the questionable way they got to the point they have. There are several other excellent Javascript libraries like SmartClient that haven't gained the recognition they deserve and community support only because they were honest and consistent in their licensing model. While its no big deal to many to buy a (currently) reasonably priced commercial Ext license, supporting such a move from LGPL to GPL is an extremely bad precedent to set in the OSS community that has flourished on the basis of trust. 作者还提到SmartClient是一个非常出色的框架,只是没有被大家认可。 |
|
返回顶楼 | |
发表时间:2008-05-21
xxqn 写道 yiaduo能否介绍一下dojo如何做package的。
这个dojo的官方站点的文档很清楚了吧。像java一样按照文件目录结构自己规划好package,比如com.xx.js.utils, com.xx.js.utils.array, com.xx.js.model 等等。 根据页面的使用情况,使用custom build做出比较多的layer.将页面上所需要的js合并成一个大的压缩过的,混淆过的js文件,尽可能的防止在页面初始化的时候进行dojo.require同步装载。那么你的应用性能无疑是最佳的,每个页面只装载需要的js内容,甚至说我只会用到某几个function,其他的不需要,那么我就不打包进来。当然如果页面有可能会用到某个function,但是用户使用的概率很小,那么这样的则可以进行同步的装载,load on demand. 当然甚至你可以自己做到在页面初始化完毕之后,采用异步的方式去装载那些并非是页面初始render时候所需要的js,这样的话,用户在需要的时候,有很大可能这个function已经在上下文中了。 |
|
返回顶楼 | |
发表时间:2008-05-21
shatuo 写道 dojo的渲染机制有没有改善方案,每个页面都渲染两次,特别是第二次,很慢的,几十控件就要近10秒钟,想想办法。
什么叫两次渲染? 不明白你的意思。 |
|
返回顶楼 | |