Portal 页面加载引擎思考(上)

本文就DNN页面生成引擎随笔与思考,同时会牵涉到CommunityServer的Skin机制、Url Rewriter、SharePoint知识。
在DNN中,只有为数不多的几个页面(.aspx),除去核心机制外,大多数业务逻辑都写在用户控件里(.ascx),那DNN是如何展现出千变万化的页面的呢?分析之后,你会发现,所谓千变万化的页面只是url rewriter结合一种页面加载(生成)引擎综合的结果。在这个加载过程中主要按如下步骤进行:
1:编写一个IHttpModule的扩展,并且捕获其中的BeginRequest事件
public class UrlRewriteModule : IHttpModule
{
    
public string ModuleName
    
{
        
get return "UrlRewriteModule"; }
    }

        
    
public void Init (HttpApplication application)
  
{
        application.BeginRequest 
+= new System.EventHandler(this.OnBeginRequest);
    }


    
public void OnBeginRequest (object sender, EventArgs e)
    
{
        
//处理逻辑
    }

}
在Url Rewriter处理逻辑里,一般会用到正则表达式来进行Url 的匹配。以DDN为例子,几乎所有(但不是全部)的页面请求都被Rewriter到default.aspx页面,只是default.aspx后面的QueryStrings(url 问号后面的参数)不同(这很重要)。
2:有了上面的步骤,现在可以把焦点集中在default.aspx页面里,但是default.aspx页面里并没有放置所有的业务逻辑,而只有一个容器(placeholder一类的东西),余下的就是加载用户控件(.ascx)到这个容器里了。DNN中采用了和CommunityServer类似的方式来加载用户控件(.ascx),但显得没有CommunityServer高明,至少从MVC或MVP模式来看是这样。作为Portal,加载控件用户控件只不过是程序员理解的行为,从维护门户的管理人员来看,这还会复杂一些。在DNN中,在页面加载时,用户控件(.ascx)会被赋予不同的使命,有Skin,Container,以及Module(对于这几个词汇,我更喜欢这样称呼他:Skin-->Layout、Container-->Zone,Module-->Module or Part)。他们之间是存在包含关系的,Skin 就是页面的布局,在Skin中包含有一个或多个Container,Container中用来装载Module。 其实在sharepoint 中Container叫WebPartZone,而Module叫WebPart,这样似乎会好理解一些。
3:在第一个步骤里,我们得到一些 QueryStrings,有了他们就可以通过数据库或者配置文件去加载不同的Skin、Container与Module,而Skin通过public Control LoadControl (string virtualPath )来加载Container,同样,Container也通过它来加载Module。

至此,页面就被呈现给用户了。
有待进一步思考:
以上过程看似简单,但是要处理好这些URL还真不是件容易的事情,DNN中花费大量的代码来做URL处理与QueryStrings判断,但URL还是不够友好,而SharePoint显得在URL上美观很多。
效率问题,Portal大多访问量较大,类似DNN这样多嵌套与多用户控件的加载效率上不容乐观,SharePoint也有类似问题。
页面呈现的层次结构,DNN的Portal->Tab(Page)->Module或者SharePoint的Portal->Site->Page->WebPart,哪一种更能体现用户需求。

posted on 2007-04-28 13:50  彭斌  阅读(1344)  评论(2编辑  收藏

导航