我们看到，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的主要服务之一博客来说，个性化相当重要。
