认识Dojo中的界面控件：Dijit

那这种情况呢？
有个组件，模块1和模块2都会使用到，那么是将它同时合入模块1和模块2的包呢？还是合入公共包？还是说模块1和模块2合并？
要知道组件多了之后，这种事情很常见，大部分组件都有些重用，但又并不是那么“公共”

如果不追求那么一点性能，同步加载真的合适。。。不会出错，理解简单。
而异步加载还要弄回调

有点走题了。。。我比较关注的是Dojo的内存释放和组件布局性能。

又重新认识了一下Dijit,写的很棒!

如果说这个组件仅被模块一和模块二公用，那么说明这2个模块具有相当的其它模块没有的共性，他们应该合并。
如果你发现模块1，2还和其它模块有千丝万缕的联系，没法分的很开。那说明真的不需要分开了。用一个比较漂亮的进度条，是个很好的解决办法。当然，也许你也要看看对模块的划分和设计是否合理。

关于内存释放，这个可以说是最头疼的问题，任何框架都是如此。因为在很大程度上这依赖于开发人员的水平。对于Dojo来说，最重要的是做好disconnect。Dojo本身的代码都经过严格测试，不会有内存泄露的问题。

布局组件本身性能很好，如果你发现性能降低，那就需要看你往里面加了什么了。下面的链接可以帮助你查看Dojo布局组件的功能和性能：
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/layout/

Dijit缺少一个像Extjs那样的示例展示中心
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html?theme=soria
这个链接里连最基础的Grid示例也看不到

呵呵，如果熟悉了Dojo的文件结构，其实在你这个url下是很容易找的：
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/grid/tests/
这里可以看到几乎所有Grid的用法。复杂表头，View锁定等机制都是其它Grid没有的。
同理，你可以找到任何Dijit的test case从而学习他们的用法。
这里是学习Dojo的最重要的资源，没有之一。

作为nightly build，也许没那么稳定，但你可以在release下面用同样的路径来查看。

Dojo的推广功夫确实做的不够好，不懂得适当的包装一下，呵呵

dojo最让人恶心的就是那庞大的身躯，唉，和IBM产品一个德行，似乎dojo最开始就是IBM开发的。

这个就太冤枉Dojo了。Dojo很灵活的，可以自由裁剪。就像Linux内核，核心的大概只有十几K，其它的爱怎么整就怎么整。

dojo开发的界面虽然挺好看，但是性能不是太好，速度有点慢，而且里面的registry机制注册组件和管理相关组件的ID上有些问题，比如在ajax调用的时候，ID没有自己销毁掉，要靠自己去找到那个已经不在当前页面的组件ID，并注销它。现在新版本1.5的好像性能方面没有多大改进

愿意具体讨论下你的问题，也许对大家都有帮助。为什么ajax调用时，ID（组件）要自己销毁掉？能把需求说的更详细点吗。

还有，性能问题大家都非常关注。其实各大框架的性能评测有很多，有个人的也有比较权威的。Dojo在这方面一直都是领先的，有兴趣的可以Google一下。说性能有问题的，大多就是一个感觉。希望大家能给出具体的test case来说明Dojo的性能问题，毕竟解决问题时不应该靠感觉，要靠调查和数据。比如，显示10万条记录的Grid，我重新排序的时间要多少，Render的时间要多少。这样的性能数据比较有讨论意义。

我们用dojo做过几个项目，和普通的页面比较，dojo的页面确实需要额外的渲染时间，但是和其它的ajax框架比性能没有劣势，在企业级项目中用户都能接受(第一次进入系统，javascript的加载时间稍微长点)