Baldwin's DNN-Category-解析DNN代码

吹响启动DNN 5.x的号角

dnnsun@gmail.com — Tue, 14 Jul 2009 23:31:56 GMT

如今DNN的版本很多, 4.x 仍是很普遍, 但5.x也是大势所趋, 让我们吹响DNN 5.x的号角吧, 在此跟大家一块分享最近的活动和情况, 如何优化DNN性能及其速度, 如何找回失去的ModuleConfiguration对象等等.

如何在DNN模块开发中利用缓存机制？

dnnsun@gmail.com — Wed, 04 Feb 2009 15:18:25 GMT

在Asp.Net开发过程, 缓存是我们经常遇到的问题, 同样在DNN模块开发中利用好缓存无疑对我们开发的模块是有显著性能提升的效果的。本文将介绍DNN核心API自带的缓存机制及其一些使用方法.

Cambrian和Open Force '08专题(不断更新中,敬请关注)

dnnsun@gmail.com — Wed, 16 Jul 2008 05:17:07 GMT

临近DNN Open Force '08, 难免会有跟风之嫌, 我也不例外, 故在此作一个Cambrian和Open Force '08专题, 分享一些DNN下一代版本"Cambrian"的资源, 算是聊解我们这些DNN Fans对它望眼欲穿的期盼, 详细资源将不断更新中,敬请关注...

DNN核心API简述

dnnsun@gmail.com — Mon, 14 Jul 2008 05:02:58 GMT

DotNetNuke本身可以看作是一个框架, 类比于.net framework, 你可以在基础上扩展并实现各种功能, 而其中不可或缺的就是核心API, 它是你在开发过程中最有力的辅助工具, 而了解API最基本的步骤就是API组织起来的命名空间, 废话少说, 在此简单介绍一下DNN模块开发过程中最经常使用到的命名空间列表:
DotNetNuke.Common: 可被用于整个DNN应用程序的所有类, 比如其中的global实例就是荟萃了所有DNN全局的静态方法, 可被直接用于整个DNN应用程序, 而global就位于命名空间DotNetNuke.Common.Globals之下.
DotNetNuke.Data: DNN核心数据层, 可被用于扩展数据层, 比如我们最熟悉的DataProvider基类及其API就位于命名空间DotNetNuke.Data之下.
DotNetNuke.Entities: DNN核心实体类, 主要负责实例化和管理组成DNN Portal的核心实体, 其中包括Host, Portals, Tabs, Users, Profile, and Modules. 每一实体都独立分支并形成自己的二级命名空间, 比如负责管理模块的实体类位于DotNetNuke.Modules之下.
DotNetNuke.Framework: DNN框架类, 主要管理一些DNN框架的扩展辅助类, 比如DNN对Ajax的支持, 对CDefault的衍生等等.
DotNetNuke.Security: 主要用于DNN的授权及其验证. 其中包括了页面权限(tab permissions), 模块权限(module permissions), 文件夹(folder permissions), 角色管理(roles manage)等等.
DotNetNuke.Services: DNN核心服务, 比如异常处理, 本地化支持, 用户定制(personalization), 搜索引擎, 缓存优化, Mail分发等等.
DotNetNuke.UI: DNN核心UI, 比如DNN特有的Skin 和 Container就分别位于DotNetNuke.UI.Skins.Skin 和 DotNetNuke.UI.Containers.Container之下, 除此之外,还包含一下些UI设计扩展的辅助类DotNetNuke.UI.Utilities, 大名鼎鼎的ClientAPI就位于该命名空间.
相关链接:
DNN模块开发之利器篇:七种武器

如何在DNN创建类IGoogle效果的模块

dnnsun@gmail.com — Tue, 08 Jul 2008 14:59:07 GMT

借助Blog的一个扩展模块展示如何在DNN实现类IGoogle模块?算是抛砖引玉，为大家提供一种新的思路，感兴趣着不妨看看...

DNN Skin旅程之琐碎杂想

dnnsun@gmail.com — Mon, 30 Jun 2008 12:09:39 GMT

一直有人跟我提为何不做一些DNN皮肤教程什么的，本人甚为惭愧，当初曾夸下海口说没问题，可一拖再拖，倒不是自己没有时间，只是姑且不论自己设计能力的肤浅，光是那一系列教程制作就得花费不少心思，至少得简单易懂吧？至少得图文并茂吧？至少得符合CSS，W3C吧？我可不想随便拿出一样拷贝别人的皮肤来炫耀自己的水平。故折中的做法只能随时分享自己设计开发皮肤的一些经验或想法，希望能满足部分读者的口味。

在DNN中处理回车键事件

dnnsun@gmail.com — Wed, 18 Jun 2008 09:35:57 GMT

分享项目开发中的小技巧:如何处理回车键事件, 特别是在同一个页面可能同时存在多个通过回车键提交表单时执行特定的button按钮事件的情况下. 详情请查看原文...

解除DNN的传参枷锁

dnnsun@gmail.com — Sun, 01 Jun 2008 11:49:54 GMT

在上一篇文章中曾提及在DNN模块开发中传参的两种方式，其中包括ASP.NET中经典的URL传参方式，然而尽管如此，对于一些DNN初学者来说还是无从下手，这里我就简单解析其中道理及其如何在页面跳转，模块交互过程中最有效地传递参数，从而达到解除DNN之枷锁的功效。

剖析DNN架构-开篇之作

dnnsun@gmail.com — Mon, 26 May 2008 13:35:38 GMT

本Blog将新增一个栏目，暂时取名为"剖析DNN架构",名号似乎有些大了，但考虑到这也算是鞭策所写文章质量的一种手段，故最后暂且不做更改了。对于为何出现这一栏目，主要是一直以来跟一些DNN爱好者们的交流所促使的。曾有几位朋友所在公司想利用DNN这一开源平台或开发产品，或与现有系统整合，或优化框架以便满足需求等等，故他们都愿意招聘能真正担当起这一重担的“千里马”，想想这将要求所聘之人具备以下一些条件:

1) 熟悉DNN核心架构和框架脉络。
2) 有一定的架构经验，懂得设计模式相关知识。
3) 精通DNN模块开发流程及其皮肤机制。

等等，“DNN架构师”也就从此诞生了，当时我听到他们的招聘要求之后,唯一的想法是在国内，此等“千里马”实在是凤毛麟角，恐怕他们只能望梅止渴了。因为想想国内研究DNN的氛围,人气之淡，交流之稀，凭何能促进DNN这一开源平台的兴盛呢？

对于DNN入门的门槛，就我个人的观点还是蛮高的，当然你想借助DNN搭建一个网站倒是及其容易的，也就是1-3分钟即可，而目前DNN模块及其皮肤资源还是蛮多的（其中包括免费或商业的),只要你合理利用还是可以满足大部分需求的。但如果你想定制业务或布局修改的话，那就必须得了解一些编程技巧或HTML，CSS布局原理等。对于非专业人员，恐怕是力所不及的。而对于刚入门的开发人员，你需要了解的更多，其中包括DNN基本架构，模块开发流程，API调用等等，想真正开发一个高级模块，也不是一蹴而就的。最不幸的是，由于国内相关资源的欠缺，一些刚入门者屡屡碰壁也就不足为怪了，在此我还是鼓励大家,如果你想真正好DNN，那么请你耐着性子看看英文资料吧，其中包括DNN官方的第一手资料。相反，可喜的是如今大家已经逐渐看好DNN，各方面应用不断涌现，比如电子商务，游戏站点，社区论坛，ERP整合，电子政务等等，可以这么说，DNN应用在国内这一潜在市场正在形成中，群雄逐鹿，看看你是否可以在此市场中分得一杯可观的羮。

最后，再聊点本人认识的DNN，DNN可算是.net下最大的开源平台，其优势是显而易见的，其地位也是举足轻重的，DNN可谓为Microsoft也作出了相当大的贡献，想想DNN本身是VB.Net开发的，这也可以理解为留住VB开发人员的一个诱饵吧，更深的一层就是由DNN带动的.net项目不在少数，曾有官方数据对此进行佐证，可惜我没有记得链接，似乎是DNN OpenForce '07大会统计的。记得前些日子，也曾有小道消息称，Microsoft将收购DNN所属公司，将其商业化，集成到某一产品中，这可谓不振耳发聩。后来知晓此为子乌虚有，但同时也不禁为DNN未来之命运所担忧，一个纯开源的项目在"不开源"的Microsoft国度是否可以一帆风顺，茁壮成长呢？是否将半路夭折呢？是否将穷途末路呢？如今VS 2008 已粉墨登场，ASP.NET Ajax Framework也横行了半边天，如果说DNN当初的Membership,"拖拽"（clientAPI之威力)是值得炫耀的话，现在已是烟飞灰灭了,Membership早整合到Framework中，而DNN"拖拽”功能实质是中看不中用的“幌子"(只能吊吊客户的胃口),早已是明日黄花,也就是说这些技术的实现现在已是举手之劳，看看iGoogle, dropthings。不知你是否同意我的观点？说到此，不妨看看我所认识周围的DNN开发人员或项目经理是如何评价DNN的？老实说,"牛"些的哥们都不看好DNN，有的甚至在开发过程中不断唾弃DNN,指责公司乃至项目为何选择这一“垃圾”平台;有的看清其架构之后就将其摒弃于墙角；有的曾经研究过，最后抛弃了DNN。理由是各式各样的，但整理起来无非主要有以下几点（仅供参考):

1) DNN最初的框架并非是最优的(其鼻祖是IBuy Portal),而之后为了兼容性对于一些性能的提升等也只能作折中的妥协处理，故理智的对待DNN性能问题是你选择DNN首先值得参照的一点，其他可想而知。

      2) DNN是一个理想的内容管理系统,其效率足于让你瞠目结舌，但若想在其框架上开发业务比较复杂的项目，比如前边提到的电子商务，ERP等等，那你就得慎重考虑了，尽管有过成功的范例，比如最知名的CataLook电子商务套件模块就可以满足一般的电子商务需求。但风险依然存在，因为DNN一直以来存在一个"致命之症",当初引入了模块开发插件化理念，同时也引入了这一隐患，那就是DNN每个模块都是独立的，它们相互之间是不可知的，从而导致页面跳转及模块交互变得错综复杂，这也是初学者最不可理喻的，无从下手之处，如今DNN经典而常用的传参方式无非有两种方式:
     <1>URL传参，也就是利用URL将参数传递到目的页面，优点是清晰明了，缺点是安全性极低。以后我会专题介绍在DNN模块交互如何用URL方式最好最优的传递参数。(文章已添加，请参看"解除DNN的传参枷锁")
     <2>IMC传参，即是DNN默认实现的模块交互接口，鼎鼎大名的Inter Module Communication,关于如何使用IMC，官方曾有文档对此有所提及，但是不详细，我之前曾写过相关文章:

DNN特性之IMC

   以下链接也是一份详细教程，有兴趣者不妨看看:
      DotNetNuke Inter-Module Communication or: How Your Modules Can Get Their Chat On
      正是由于以上所列举之局限，在DNN中开发复杂应用须清楚其中潜在的风险，本人所碰到的项目最初选择DNN，最后抛弃DNN也有好些，当然也有些勉勉强强搭上DNN的末班车，但那也不过是无奈之举，因为此时重构或重新开发已是不可能的。

3)DNN永远是Microsoft国度的一员，这将摆脱不了它的命运，此为幸事，此为不幸也。“幸”指的是将有Microsoft这一霸主的后台支持，无疑是客户选择平台最为看重的一点。“不幸”则指它将笼罩在Microsoft的阴影下，属于自己的东西将逐渐越来越少，想想ClientAAPI为了整合兼容ASP.NET Ajax Framework就大刀阔斧的删减了不少脚本，这是优化的代价，也是失去。

好了，就此打住，下次希望能给大家更清晰的DNN架构解析以飨读者。

DNN模块开发之利器篇:七种武器

dnnsun@gmail.com — Fri, 23 May 2008 10:23:53 GMT

读过武侠小说的你一定都知道古龙曾有一部著名的小说<<七种武器>>,其中列举了当今武林最牛的,杀伤力最大的武器,其中包括长生剑、孔雀翎、碧玉刀、多情环、霸王枪、离别钩、拳头.后来还有百晓生的兵器排行榜,其中就包括小李飞刀等等.在此我就班门弄斧了,借着古代利器之说,姑且列举一些对DNN模块开发起决定作用的一些方法或类,并辅助说明使用方式(排名没有先后之分,纯粹用于标识):

1) PortalModuleBase

所属命名空间:DotNetNuke.Entities.Modules

这是一个开发DNN模块所必须继承的基类,标志性的基类,在此基类中,你可以得到DNN所为你封装的一些模块基本信息,毋需你多费周折,其中包括当前用户UseID,UserInfo,TabID,ModulePath,ModuleConfiguration,LocalResourceFile等等,下边就简单解析几个比较有用的属性:

<1> ModulePath: 模块根目录,可以获取到模块根目录所需要的文件,比如脚本文件,图像文件,比如你想在后台注册一个js脚本,代码可以类似:

ScriptManager scriptManager = ScriptManager.GetCurrent(Page);
scriptManager.Services.Add(new ServiceReference(this.ModulePath + "WebService.asmx"));
scriptManager.Scripts.Add(new ScriptReference(this.ModulePath + "js/Utility.js"));

<2> LocalResourceFile: 本地化资源文件,默认是关联到模块根目录下的App_LocalResources下对应文件,比如你开发的模块用户控件为xx_view.ascx,那LocalResourceFile就是App_LocalResources/xx_view.ascx.resx(或xx_view.ascx.zh-CN.resx),如果你想手动的注册本地化支持,代码可以类似:

lblMessage.Text = Localization.GetString("Message", LocalResourceFile)

更高级的应用可能就是设置共享本地化资源,也就是说你可以好些UserControl共享一个资源文件,比如你可以设置一个共享资源文件SharedResources.resx(或SharedResources.zh-CN.resx),专门放置一些公共的本地化键值对设置,然后添加如下方法到你的基类或后台代码,这是一个值得推荐的方法,节省了资源文件的大小(如果说你开发的模块比较复杂的话,文件的统筹规划是必不可少的):

Public Function LocalizationByKey(ByVal key As String, Optional ByVal IsSharedResource As Boolean = False)
If IsSharedResource Then
Return Localization.GetString(key, SharedResourceFile)
End If
Return Localization.GetString(key, LocalResourceFile)
End Function

<3> ModuleConfiguration: 当前用户控件所在的模块配置信息,比如动态设置模块标题,是否显示模块容器,是否支持打印或聚合等等.比如通过以下代码你就可以动态的修改模块标题:

If Not Null.IsNull(UserId) Then
ModuleConfiguration.ModuleTitle = Localization.GetString("UpdateUserInfo", LocalResourceFile)
Else
ModuleConfiguration.ModuleTitle = Localization.GetString("ModuleTitle", LocalResourceFile)
End If

2) AJAX

所属命名空间:DotNetNuke.Framework

DNN核心封装支持Ajax功能的辅助类,其中包含了一些及其有用的方法,比如:
IsInstalled(): MS Ajax是否安装
IsEnabled(): MS Ajax是否激活
RegisterPostBackControl: 注册传统PostBack控件
RegisterScriptManager: 注册ScriptManager
等等.
现举一个应用例子:

/// <summary>
/// Register the background Webservice and js-script
/// </summary>
private void RegisterAjaxWebservice()
{
if (DotNetNuke.Framework.AJAX.IsInstalled())
{
DotNetNuke.Framework.AJAX.RegisterScriptManager();
ScriptManager scriptManager = ScriptManager.GetCurrent(Page);
scriptManager.Services.Add(new ServiceReference(this.ModulePath + "ManageService.asmx"));
scriptManager.Scripts.Add(new ScriptReference(this.ModulePath + "Utility.js"));
}
}

3) ModuleSettingsBase

所属命名空间:DotNetNuke.Entities.Modules

这是DNN模块设置的基类,其中主要包含两个方法,LoadSettings和UpdateSettings,当你继承于它时,你所需要就是重写这两个基类方法,方法体实现业务逻辑,关联的数据库表为TabModuleSettings或ModuleSettings,这两个都具有同样的数据结构,存储就是类似哈希表的键值对,所不同只是他们更新数据的方法不一样而已:

Dim objModules As New DotNetNuke.Entities.Modules.ModuleController
objModules.UpdateModuleSetting(ModuleId, "timeinterval", txtTimeInterval.Text.Trim.ToString())
Dim objModules As New DotNetNuke.Entities.Modules.ModuleController
objModules.UpdateTabModuleSetting(ModuleId, "timeinterval", txtTimeInterval.Text.Trim.ToString())

而当你仔细参看代码,在方法中LoadSettings所使用的Settings实质就是TabModuleSettings和ModuleSettings的合并,当然你也可以自行获取TabModuleSettings或ModuleSettings,dnn给与你更多的控制权:

Public Shadows ReadOnly Property Settings() As Hashtable
Get
If _settings Is Nothing Then
'Merge the TabModuleSettings and ModuleSettings
_settings = Portals.PortalSettings.GetTabModuleSettings(New Hashtable(ModuleSettings), New Hashtable(TabModuleSettings))
End If
Return _settings
End Get
End Property

更多信息你可以参看dnn核心模块,比如Survey,Link等等.

4) CDefault( or PageBase)

所属命名空间:DotNetNuke.Framework

PageBase是DNN核心页面基类,而CDefault是对此有所封装的类,两者何时需要主要看你的开发需要,在此我就分别举两个例子:

<1>一般模块中的aspx需要继承PageBase,PageBase主要有LocalResourceFile,PortalSettings等属性,比如你模块中存在一个Print.aspx,后台代码可以如此声明:

Partial Public Class Print
Inherits PageBase
End Class

<2>模块里的用户控件如果需要控制页面信息时,可以新增一个属性BasePage,代码如下:

Public ReadOnly Property BasePage() As DotNetNuke.Framework.CDefault
Get
Return CType(Me.Page, DotNetNuke.Framework.CDefault)
End Get
End Property

这时你就可以在用户控件加载时动态修改页面相关属性,比如Title:

Me.BasePage.Title = Me.BasePage.Title & " - " & m_oEntry.Title

本站点博客模块就是如此动态设置页面标题的.

或你可以直接如此设置:

'Override the page title
Dim myPage As DotNetNuke.Framework.CDefault
myPage = CType(Me.Page, CDefault)
myPage.Title = Localization.GetString("ControlTitle_YourPage", Me.LocalResourceFile)

5) Globals

所属命名空间:DotNetNuke.Common

这是DNN模块开发用得最多的一个静态类,汇聚了DNN核心最基本的静态方法,如果你有心想开发好模块,好好看看这里边的方法,你会有意想不到的收获.比如:
<1>ConvertDataReaderToDataTable:把DataReader转化为DataTable
<2>ConvertDataReaderToDataSet:把DataReader转化为DataSet
<3>NavigateURL:最经典的DNN导航(跳转)函数
<4> SendMail:DNN核心发送邮件方法
<5>FriendlyUrl:友好URL重写方法
<6>GetFileList:获取DNN站点根目录下文件列表,如果你在用UrlControl你会觉得这个方法是你所必须知道的.
等等.

6) CBO ( and Null )

所属命名空间:DotNetNuke.Common.Utilities

这是DNN模块数据层所必备的一个工具类,对此我也曾专题般的讨论过,合理的使用CBO决定你即将开发的模块的命运,比如扩展性,兼容性,维护代价等等.

相关链接:

解析DNN新生宠儿DAL+

DNN Object Hydrator -- CBO解析

王者归来—再谈CBO

7) DNNClientAPI

所属命名空间:DotNetNuke.UI.Utilities

这是DNN赫赫有名的一个辅助类,为DNN模块开发客户端脚本和服务器交互起到不可或缺的作用,同时支持本地化使得脚本也真正实现了本地化.最经常使用例如我们需要在点击某一个删除按钮弹出提示信息,如今在DNN模块及其简单,就是一句代码即可:
ClientAPI.AddButtonConfirm(cmdAddComment, LocalizationByKey("cmdDeleteCommentMessage"))
在此再举一个比较经典的应用范例,有时我们需要在客户获取目标控件并对此操作,可由于ASP.Net(DNN)在生成页面时已自动生成客户端代码,比如某一TextBox控件screenName最终可能会生成类似dnn_ctr431_QuickLogin_screenName,如果你在客户端脚本中直用document.getElementById('cmdHome')获取该控件的话,只会返回一个undefined或null,这时就需要我们在客户端注册一个页面ID前缀,而DNN早为我们想到了,那就是dnn.js脚本为我们提供两个方法dnn.gerVar和dnn.setVar,具体流程就是首先在页面注册页面前缀:

ClientAPI.RegisterClientReference(this.Page, ClientAPI.ClientNamespaceReferences.dnn);
ClientAPI.RegisterClientVariable(this.Page, "Container_ID", this.ClientID + "_", true);

然后在脚本中你可以直接得到你想要的控件对象:

var _ModuleContainer;
if( typeof(_ModuleContainer) == 'undefined' ) _ModuleContainer = dnn.getVar('Container_ID');
var screenName = $get( _ModuleContainer + 'screenName').value;