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

你可能感兴趣的:(text)