解析DNN代码
研究一些DNN最核心代码,挖掘最有价值的核心代码,模块开发可以借此达到最DNN的境界...
如今DNN的版本很多, 4.x 仍是很普遍, 但5.x也是大势所趋, 让我们吹响DNN 5.x的号角吧, 在此跟大家一块分享最近的活动和情况, 如何优化DNN性能及其速度, 如何找回失去的ModuleConfiguration对象等等.
Read the rest of entry »
在Asp.Net开发过程, 缓存是我们经常遇到的问题, 同样在DNN模块开发中利用好缓存无疑对我们开发的模块是有显著性能提升的效果的。本文将介绍DNN核心API自带的缓存机制及其一些使用方法.
Read the rest of entry »
临近DNN Open Force '08, 难免会有跟风之嫌, 我也不例外, 故在此作一个Cambrian和Open Force '08专题, 分享一些DNN下一代版本"Cambrian"的资源, 算是聊解我们这些DNN Fans对它望眼欲穿的期盼, 详细资源将不断更新中,敬请关注...
Read the rest of entry »
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模块开发之利器篇:七种武器
借助Blog的一个扩展模块展示如何在DNN实现类IGoogle模块?算是抛砖引玉，为大家提供一种新的思路，感兴趣着不妨看看...
Read the rest of entry »
一直有人跟我提为何不做一些DNN皮肤教程什么的，本人甚为惭愧，当初曾夸下海口说没问题，可一拖再拖，倒不是自己没有时间，只是姑且不论自己设计能力的肤浅，光是那一系列教程制作就得花费不少心思，至少得简单易懂吧？至少得图文并茂吧？至少得符合CSS，W3C吧？我可不想随便拿出一样拷贝别人的皮肤来炫耀自己的水平。故折中的做法只能随时分享自己设计开发皮肤的一些经验或想法，希望能满足部分读者的口味。
Read the rest of entry »
分享项目开发中的小技巧:如何处理回车键事件, 特别是在同一个页面可能同时存在多个通过回车键提交表单时执行特定的button按钮事件的情况下. 详情请查看原文...
Read the rest of entry »
在上一篇文章中曾提及在DNN模块开发中传参的两种方式，其中包括ASP.NET中经典的URL传参方式，然而尽管如此，对于一些DNN初学者来说还是无从下手，这里我就简单解析其中道理及其如何在页面跳转，模块交互过程中最有效地传递参数，从而达到解除DNN之枷锁的功效。
Read the rest of entry »
本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大会 ...
Read the rest of entry »
读过武侠小说的你一定都知道古龙曾有一部著名的小说<<七种武器>>,其中列举了当今武林最牛的,杀伤力最大的武器,其中包括长生剑、孔雀翎、碧玉刀、多情环、霸王枪、离别钩、拳头.后来还有百晓生的兵器排行榜,其中就包括小李飞刀等等.在此我就班门弄斧了,借着古代利器之说,姑且列举一些对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.as ...
Read the rest of entry »
上一篇文章简单解析了DNN多语言解决方案,其中提到了一个皮肤级别的本地化支持.这篇文章接着简单分析如何定制开发自己的皮肤对象(在dnn称之为Skin Objects),不妨来看看我们如何给DNN默认的登陆注册链接皮肤对象做个小变身.首先还是先描述一下需求,例如有客户需要在设计皮肤时可以在登陆注册这两个链接增加一个小图象提示,起到修饰美观的作用,最终效果如图:
如何开发呢?其实对我来说,开发DNN的原则就是如何节省代码量,同时可以让DNN物尽所用,但又不能影响以后的升级.我想这个理念在前几篇文章都阐述得淋漓尽致(比如浅谈如何做到dnn物尽所用(二), 浅谈如何做到dnn物尽所用).有兴趣者不妨回头看看,也许你也会得到些许提示的.回到正题,首先我想到就是利用原有的登陆注册这两个链接皮肤对象,再结合DNN自带的CommandButton(文章"再谈dnn的物尽所用(三)"对此有所解析)这一用户控件就可以实现我们的需求了.那我们就开始吧,还是我之前提到开发皮肤对象的步骤:
1) 在网站根目录下的admin/Skins文件夹里创建一个UserControl,比如现在新增dnnsunUser.ascx和dnnsunLogin.ascx(请注意该文件夹下的代码不需要重新编译,如果你是以站点形式发布的).
2) 创建对应的资源文件(dnnsunUser.ascx.resx, dnnsunUser.ascx.zh-CN.resx及其dnnsunLogin.ascx.resx,ascx.resx, dnnsunLogin.ascx.zh-CN.resx)
其中上述步骤你可以直接拷贝默认的登陆注册链接皮肤对象,然后重命名即可.接下来就是替代我们即将加入的CommandButton,在页面中注册并添加实例:
dnnsunLogin.ascx
@ Register TagPrefix="dnn" Assembly="DotNetNuke" Namespace="DotNetNuke.UI.WebControls" %>
<dnn:CommandButton ID="cmdLogin" runat="server" CssClass="SkinObject" CausesValidation="false"/>
或
dnnsunUser.ascx
@ Register TagPrefix= ...
Read the rest of entry »
在DNN使用中，我们可能有这样的需求，那就不想开放过多的权限给管理员以防止误删的事件，当然可能也有这样的需求， 增加某一个管理页面，对此的一般做法设置为管理员可见，这样就可以保证只有管理员才能查看和编辑这个页面，但是红色的边框提示确实比较难看，或许你需要把这个页面加入到admin或者host菜单，这样更方便管理和显得合理。在这里我们列举如何利用SQL Script来实现(当然也可能也有其他方法，但SQL应该是比较方便和直接的，前提你具有host帐号权限),接下来我们就分别对这两种情况讲解.
注意：以下更改之后必须重启IIS方才生效。
1) 屏蔽某些管理页面，也就是隐藏这些页面,最简捷的解决方案就是把类似以下的脚本拷贝到 主机管理/SQL服务下 当作脚本执行即可隐藏这些页面,不过缺点也是明显,如果你直接拷贝原来的Url仍然可以访问这一页面,实质就是我们只不过玩弄一下技巧吧了,当然你也可以设置IsDeleted或DisableLink这一属性,这就可以彻底的防止通过Url访问了。
UPDATE {databaseOwner}[{objectQualifier}Tabs]
SET [IsVisible]='0' -- Apply to the admin tab to not show
WHERE tabid=52
2) 增加管理页面并加入网站管理或主机管理菜单中。
首先我们新建一个页面，要记得查看页面id并记录下来 ,页面权限为正常即可，不必设置为管理员可见，然后添加管理模块到该页面,之后把类似以下的脚本拷贝到 主机管理/SQL服务下 当作脚本执行即可完成把管理页面改到管理菜单下
UPDATE {databaseOwner}[{objectQualifier}Tabs]
SET [TabOrder]='10032',
[IsVisible]='1',
[PortalID]=0, -- the filed related to which portal the admin menu exist
[ParentID]='38',
[Level]='1', -- the filed is the menu level, 0 is 1st, 1 apply to 2st...
[TabPath]='//Admin//YourTabName', -- YourTabName is your tabName which you will insert into the admin menus
[IconFile]='yourTabimage src' -- this filed is optional
WHERE tabid=57
参数解析:
1) TabOrder: 站点管理菜单TabOrder值截止到10031，也就是说你可以用10032 10033 10034……
2) ParentID: ParentID的计算，站点ID为0时，ParentID为38，站点ID为1时，ParentID为56，站点ID为2时，ParentID为74，站点id加1，ParentID加18
portalid=0 ParentID=38
portalid=1 ParentID=56
portalid=2 ParentID=74
portalid=3 ParentID=92
……
这一方法待考证.
3) tabid: 你要加进管理菜单的页面的id
类似如果想要把管理菜单写入host菜单下，需要修改语句如下：
UPDATE {databaseOwner}[{objectQualifier}Tabs]
SET [TabOrder]='24',
[IsVisible]='1',
[PortalID]=null,
[ParentID]='7',
[Level]='1', -- the filed is the menu level, 0 is 1st, 1 apply to 2st...
[TabPath]='//Host//YourTabName', -- YourTabName is your tabName which you will insert into the admin menus
[IconFile]='yourTabimage src' -- this filed is optional
WHERE tabid=57
1) TabOrder: TabOrder主机管理菜单TabOrder值截止23,你可以用24 25 26……
2) PortalID: 主机管理菜单PortalID值不变,因为主机管理是全局的,故PortalID默认为NULL
2) ParentID: 类似PortalID，因为主机管理是全局的,故ParentID一般为7
3) tabid: 你要加进管理菜单的页面的id
当然还可以在Admin或者是Host菜单下添加二级管理菜单,只需要加上TabPath='//Admin//一级//二级//…',