DotText源码阅读(6) --模版皮肤
DotText源码阅读(6) --模版皮肤 我们看到，dottext的个人模版是可以替换的，但显然，这么多套模版不可能每一套都写一个包含界面的程序文件。dottext的作者采用了UrlRewrite来实现模版和换肤，我们分析其原理后，可以明确如何做到为blog增添新的模版，实现站点blog的个性化。说到这个性化，可是web2.0的命根子！就以本人的blog为例来说明吧：假设我们访问http://blog.csdn.net/shanhe ,http请求会经由IIS传给asp.net的进程（通过管道交互数据），而blog.csdn.net这是一个应用程序，web.config起作用了，它的请求由<addverb='*'path='*'type='Dottext.Common.UrlManager.UrlReWriteHandlerFactory,Dottext.Common'/>而被UrlReWriteHandlerFactory 接管。在该工厂处理例程中，会取出当前请求的URL:string appStr=Dottext.Framework.Util.Globals.RemoveAppFromPath(context.Request.Path,context.Request.ApplicationPath);此时得到的 context.Request.Path 为 /shanhe 而 Request.ApplicationPath 为 “/”经过替换后的到 appStr为 “/shanhe”,这个同<HttpHandlerpattern='^(?:\/(\w|\s|\.(?!aspx))+((\/default\.aspx)?|(\/?))?)$' controls='homepage.ascx'/>指定的pattern 相匹配。此时的HandlerType为Page,自然执行到case HandlerType.Page://默认是Page return ProccessHandlerTypePage(items[i],context,requestType,url); 我们再进入ProccessHandlerTypePage private IHttpHandler ProccessHandlerTypePage(HttpHandler item, HttpContext context, string requestType, string url) { string pagepath = item.FullPageLocation; if(pagepath == null) { pagepath = HandlerConfiguration.Instance().FullPageLocation; } HandlerConfiguration.SetControls(context,item.BlogControls); IHttpHandler myhandler=PageParser.GetCompiledPageInstance(url,pagepath,context); return myhandler; }item为匹配的handler的FullPageLocation，通过阅读 handler的尸体类可以看到属性：private string _fullPageLocation; public string FullPageLocation { get { if(this._fullPageLocation == null && PageLocation != null) { this._fullPageLocation = HttpContext.Current.Server.MapPath('~/' + PageLocation); } return this._fullPageLocation; } }这里的fullPageLocation没有指定，为null,进入后执行 pagepath = HandlerConfiguration.Instance().FullPageLocation; 此处又有反序列化，会进入HandlerConfiguration的静态函数Instance： public static HandlerConfiguration Instance() { return ((HandlerConfiguration)ConfigurationSettings.GetConfig('HandlerConfiguration')); } 此时pagepath得到了值为web.cofig中指定的 defaultPageLocation='default.aspx',由于this._fullPageLocation = HttpContext.Current.Server.MapPath('~/' + PageLocation); 会将缺省文件定位到blog站点的实际应用程序路径跟目录下的deafault.aspx,可能形如：'X:\CNBlogsDottext\DottextWeb\default.aspx',asp.net会通过 PageParser.GetCompiledPageInstance(url,pagepath,context);执行这个文件。由此客，进入了skin的执行阶段。 Default.aspx很简单，仅仅包含了数个嵌套的容器控件<body> <form id='Form1' method='post' runat='server'> <DT:MASTERPAGE id='MPContainer' runat='server'> <DT:contentregion id='MPMain' runat='server'> <asp:PlaceHolder id='CenterBodyControl' runat='server'></asp:PlaceHolder> </DT:contentregion> </DT:MASTERPAGE></form></body>MASTERPAGE的源代码（没有UI部分） 在dottextweb\ui\webcontrols\下，需要阅读的是该控件的属性public string TemplateFile { get { if(this.templateFile == null) { BlogConfig config=Config.CurrentBlog(Context); //读取blog配置，根据 if(config!=null) { this.templateFile = config.Skin.TeamplateFilePath; } } return this.templateFile; } set { this.templateFile = value; } }通过BlogConfig config=Config.CurrentBlog(Context); 读取blog配置，涉及到DTO部分，请参考前面的阅读。反正是取出来了当前我们要访问的blog的全部配置信息,将skin名称获取到。 此时我们要开始进入页面声明周期的分析了： 通过实例化Page对象后，即进入了初始化阶段（Initialize）,会调用Page_Onint事件并相应进入各个也面控件的OnInit方法，并递归到子控件的OnInit。Default.aspx主要控件是MASTERPAGE，此控件的OnInit是这样的： protected override void OnInit(EventArgs e) { this.BuildMasterPage(); this.BuildContents(); base.OnInit(e); } 分别执行 加载子控件（BuildMasterPage）的过程和生成子控件实例（BuildContents）的过程： private void BuildMasterPage() { if (this.TemplateFile == null || this.TemplateFile == string.Empty) //取得模版名称，如果不存在或者未指定那么就大祸了，抛出一个例外吧 { throw new ApplicationException('TemplateFile Property for MasterPage must be Defined'); } this.template = this.Page.LoadControl(this.TemplateFile); this.template.ID = this.ID + '_Template'; int count = this.template.Controls.Count; for (int index = 0; index < count; index++) { //注意 收集的遍历删除代吗 Control control = this.template.Controls[0]; this.template.Controls.Remove(control); if (control.Visible) { this.Controls.Add(control); } } this.Controls.AddAt(0, this.template); }`分析class SkinConfig不难得到 this.Page.LoadControl(this.TemplateFile);是指向skin目录下的某个子目录的PageTemplate.ascx,这个实际上才是模般的展示“舞台”。PageTemplate实际上包含了其所在目录的子目录controls目录中的大部分控件，在执行 this.template.ID = this.ID + '_Template'; 进行命名后，dottext又利用一个循环将全部的PageTemplate包含的子控件一一装载（当然是必须是可Visible的）。BuildMasterPage实际上模仿的就是asp.net的装载包含子控件的页面的内部细节。随后的BuildContents则把BuildMasterPage的到全部子控件进行加载到用于将 contentregion 控件（这是一个容器控件）：private void BuildContents() { foreach (ContentRegion content in this.contents) { Control region = this.FindControl(content.ID); if (region == null || !(region is ContentRegion)) { throw new Exception('ContentRegion with ID '' + content.ID + '' must be Defined'); } region.Controls.Clear(); int count = content.Controls.Count; for (int index = 0; index < count; index++) { Control control = content.Controls[0]; content.Controls.Remove(control); region.Controls.Add(control); } } }加入的条件是在ContentRegion实例的现实范围内（刚刚提到的“舞台”）。为什么要这样呢，因为this.Page.LoadControl(this.TemplateFile);这句话是装入一个用户控件，而用户控件自身其实是一个页面，那么为了整个最终给用户浏览到的页面的命名完整性，需要对全部控件的命名按照容器的规则重新命名，以免冲突。其实主要的模版的执行过程在这个Page.LoadControl(this.TemplateFile)，它会装入你在申请blog的时候特定模版下的模版用户控件，看看 config.Skin.TeamplateFilePath;的细节，原来TeamplateFilePath属性其实就是定义了需要装入的用户控件'PageTemplate.ascx' ,只不过选择的模版不同，具体的模版路径不同，PageTemplate.ascx也就不同了，这样就实现了“换肤”。 PageTemplate.ascx主要都由PageTemplate.ascx所在目录下的子目录Controls下的一些用户控件组成，实现组成的到用户的UI部分。这些UI控件。我们知道，用户控件类似Page有2个文件组成，一个负责UI，由各种html组成，另一个文件是cs文件，执行用户控件的逻辑，并且常规情况下，他们在同一个目录下。但是在模版的实现中，dottext将UI文件（.ascx）放在不同的模版下面，而代码文件全部指向dottext 的web目录下面的UI\Controls\*.cs。这样，同一套逻辑（.cs文件）对应了N套UI的ascx文件，只要我们设定不同的skin的模版名称，就实现了自由切换模版，达到“换肤”的目的。 那知道了这个原理，我们可以在模版开发上做到两个方向发展：1、 为当前的模版添加blog上的新功能，譬如计数器（目前的版本没有）。a) 首先在web目录下面的UI\Controls中加入实现的逻辑功能的cs文件b) 在各个skin目录中加入界面实现UI元素的ascx文件c) 在 PageTemplate.ascx或者具体的某个控件中加入计数器。2、 增加新的模版。这需要我们：a) 拷贝其中一个skin，改成我们需要的名字（dottext的模版名称不知什么原因，总觉得乖乖的）b) 然后修改其中的各个用户控件，但是不要修改Inherits='Dottext.Web.UI.Controls.XXXXXX'语句（XXXXXX为某个控件名称）。这样将做到UI同逻辑的映射。c) 将skin名加入到blog的管理后台配置选项中供用户选择。 以上分析了模版的实现原理，可以帮助我们修改模版，在当前dottext设计基础上扩展新的界面元素，充分实现个性化。对于web2.0的主要服务之一博客来说，个性化相当重要。
