Posted @ 2007/10/27 20:03 By baldwin
在优化DNN的过程中我们可能注意到这一点,就是我们的皮肤文件一般都写在同一个文件，可能是skin.css或container.css, 也就是说不论我们页面加载是否应用到该样式文件里边的所有属性，我们总会必须加载这样一个CSS样式文件，尽管皮肤有很多属性并不是我们所需要的，但有时我们所创建的皮肤可能会包含好些类别的skin主题,比如专为首页显示的xx_Home.ascx,专为管理页面的xx_admin.ascx,一般的xx_skin.ascx等等,显然这些页面可能是不同的布局设计,不同的样式定义,如果这些不同的样式都在skin.css里定义的话会导致该文件冗赘,并且不能达到不同的样式的目的(前提是你使用同样的class样式定义).故此我们可以有一种新的解决方案,简约而实用,那就是我们可以把通用的样式定义在skin.css里,而一些有区别的,定制的样式我们可以新建一个跟skin一样名字的样式表文件,比如xx_admin.ascx对应新建一个xx_admin.css.而DNN加载的顺序是skin.css->xx_admin.css,如此一来即使你不想使用通用的样式(在skin.css里),你也可以在xx_admin.css里重新定义而达到覆盖的效果，并不会造成数据加载的不必要负荷，从而提高页面的加载速度。
再者还有一种情况，因为DNN是权限分离极为清晰的CMS系统，也就是一般的用户和管理员看到的菜单和操作方式是不大一样的，比如每个模块在管理员编辑状态都会呈现相关操作选项在左上角的下拉菜单(the Menu Actions)，当然这些页面也是需要样式来定义布局，故此我们可提出一种优化的解决方案，那就是那管理模式的样式定义和一般样式动态分离,也就是我们在加载皮肤时根据用户的权限加载需要的样式文件，是admin.css还是normal.css . 具体的实现是可在皮肤文件的里边添加一个动态分离样式的方法， ...
Read the rest of entry »
|
Posted @ 2007/10/27 17:14 By baldwin
我想，用过DNN本身的Blog模块的人应该都比较清楚下边列举的一些缺陷:
1) 没有目录结构,不方便blog文章的归类和搜索.
2) 没有很多的统计功能,比如阅读量，最新随笔，最新评论等等
3) 没有一些很常见但很友好的功能，比如友情链接，Blog公告，Skin主题(尽管DNN是靠skin出名的)
4) 缺乏最新Web 2.0的功能，比如Tag,digg等等
然而我们还是用上它，因为它是一直在成长的，目前可能不是最好，但以后可能是最佳的。故此我们现在根据自己的需求开发了一些很必须的功能，以后我们的这个版本也会随着DNN核心团队的升级而升级，我们的目的是能够在国内延续我们的本地化开发里程.
DNN Core Blog Module V03.03.08( dnnsun version)
修改日志:
1) 修改评论中自动换行的Bugs
2) 新增首页显示最新Blog文章的模块(可选),可订制样式显示。
3) 可订制编辑Calender控件的样式
4) 增加统计按月文章数目功能
5) 增加统计阅读次数功能
对于2)点需要说明的是，安装时是默认一起安装的，也就是说其中包括blog module 和LatestBlogEntriesList module，你在页面添加模块可选择其中之一或一起安装，比如你安装Blog模块在一个新的页面，而安装Blog扩展模块LatestBlogEntriesList在首页或其他页面，由于它们是整合而关联的，故会自动获取最新Blog信息列表.本网站首页就是如此，你不妨参考设置.
Change Log (English version):
|
Posted @ 2007/10/20 12:57 By baldwin
自从DNN 4.4版本开始, DNN主要的重心转移到性能和优化方面,由此引入了一系列的优化措施和功能的改进, 如今的DNN已是今非昔比。而在跟Web标准的靠拢方面，DNN也做出了一定的努力，比如这篇文章即将提到doctype的概念, 在文章中将详细说明DNN中doctype的用途及其优势,以此对应的优化等等。
Read the rest of entry »
|
Posted @ 2007/10/17 22:22 By baldwin
值得祝贺一下,目前DNN在.net平台上的影响力已达到了一定的程度,算是.net平台上的开源社区一朵璀璨的奇葩,以至最近DotNetNuke.com被评为.net开发人员必知的一个开发资源网站,从此可窥知DNN的潜力和发展前景.
|
Posted @ 2007/10/16 20:16 By baldwin
在此列举一些比较常用的技巧，比如如何在ModuleActions中根据用户的权限加载不同的操作选项，或比如dll程序集中嵌入资源文件以及获取所有页面Tab(排除隐藏及其删除的页面Tab)等等。。。
Read the rest of entry »
|
Posted @ 2007/10/10 8:09 By baldwin
如果你开发过DNN模块或阅读过模块的代码,你应该会知道模块控制类所经常使用的一个对象CBO,它在DNN里是大名鼎鼎的,几乎所有的模块开发都会涉及并使用这一对象,在DNN数据访问策略白皮书中，你可看到如下的架构图: 从上图我们可一目了然CBO在DNN的核心作用: 在业务逻辑层和表示层处理业务对象数据。 那究竟什么是CBO呢? CBO的全称是Custom Business Object,翻译过来就是自定义(或定制)业务对象. 它是最初DNN为了最小化移植从数据层传输来到自定义业务逻辑对象信息的代码工作量，创建了一个通用的utility类。就像 二十四画生博客提到那样,它是实现从数据库中读取数据并实例化自定义业务对象（Custom Business Object）的类。从另外一个角度来说，自定义业务对象（也可简称CBO）就是保存数据的一种方式，用这种方式能让我们更方便的在业务逻辑层和表示层采用面向对象的方法来处理数据。一般来说这个类里定义的每个属性在Datareader里都有相应的字段对应。这些映射的信息的名称和数据类型都必须是唯一的。 |
Posted @ 2007/10/7 16:38 By baldwin
是的，DNN是通过外部样式表来规划页面布局和交互界面设计的，其途径就是把所有样式文件拆分到不同的,具体的样式单(比如skin.css,portal.css)，而在页面的加载时是按照一定的优先级顺序来界定的，从而达到后一样式表能够覆盖前一样式的作用，实现我们所熟悉的CSS样式继承关系。其优先级排列如下（靠后者可覆盖前者的样式）:
1) Modules – 模块控件样式，一般定义为module.css,可选项。
2) Default – 默认网站主机样式(default.css)
3) Skin – 皮肤样式，可取名为skin.css 或 skinfilename.css
4) Container –容器皮肤样式，可取名为container.css 或 ...
Read the rest of entry »
|
Posted @ 2007/10/7 9:11 By baldwin
我想稍微使用dotnetnuke框架的DNNer都知道DNN运行速度是一个瓶颈，尽管框架一直在优化的努力中，从版本2.x到3.x，再到如今的4.6.x，性能已经有了质的飞跃，这是值得欢欣的。但我们也看到，由于一开始就引入了skin动态加载的机制及其模块插件化的模式等等，致使性能有所影响，特别是对于我们国内带宽不是特别充裕的用户来说，访问一个很一般的DNN网站也是极其难受的，可能一开始一片空白，过了几分钟突然所有的内容和图像冒出来，让你觉得很难接受如此蜗牛的加载速度.在此我冒昧以我个人的经验及其论坛的一些成型的做法罗列一些建议，希望对比较关注DNN性能的DNNer有所启发和帮助: (一)由于最先核心模块为了简单方便，在页面数据绑定上都一致使用了后期绑定反射来呈现数据信息,比如 "<%# Databinder.Eval(Container.DataItem, "Name") %>" 但同时我们也要看到这其中的利和弊,DataBinder.Eval很方便，它是ASP.NET Framework 提供的一种静态方法，计算后期绑定的数据绑定表达式并且可选择将结果格式化为字符串,使用它可消除了开发人员为强迫将值转换为所需的数据类型而必须做的显式转换。这在数据绑定模板列表内的控件时尤其有用，因为通常数据行和数据字段的类型都必须转换。但是 DataBinder.Eval 会对标准数据绑定语法带来很明显的性能损失，因为它使用后期绑定反射,只有在运行时才对所绑定的数据及其参数作绑定检查，也就是说如果你所绑定的对象类型如 ...
Read the rest of entry »
|