IDC资讯中心
1、花絮：
第一次拿到dottext时，开始让我比较觉得比较奇怪的是
一、以floerggyy注册后通过url:http://x.x.x.x/floerggyy即可进入自己的blog里
(其实忘了以前常做下载页面download.aspx也不过是处理了httphandler的虚页面而已，可能是见在.text兴奋的连这些基本常识都忘了^_^)
二、居然可以拿用户名做用户的唯一标识但在表里面没有找到做为用户名username唯一约束的东东(到现在还不清楚在数据库哪个地方设置的，有知道的请指点下)
后来通过重得注册同一用户名查看抛出的异常信息，确认确实在有username做为唯一约束的东东。
唉，看来我对数据库一无所知。
…后来决定专写一篇关于url重写的文章，后来看到dottext的原作者也简单介绍了下urlrewrite，于是这个想法就放弃了。
后来又有一些朋友问dottext关于url的问题，看来还是写吧
2、配置文件webconfig.config简单浏览
自定义配置节内容:
<configsections>
<section name=”blogconfigurationsettings” type=”dottext.framework.util.xmlserializersectionhandler, dottext.framework” />
<section name=”handlerconfiguration” type=”dottext.framework.util.xmlserializersectionhandler, dottext.framework” />
<section name=”searchconfiguration” type=”dottext.framework.util.xmlserializersectionhandler, dottext.framework” />
<section name=”microsoft.web.services” type=”microsoft.web.services.configuration.webservicesconfiguration, microsoft.web.services, version=2.0.0.0, culture=neutral, publickeytoken=31bf3856ad364e35″ />
<section name=”codehighlighter” type=”actiprosoftware.codehighlighter.codehighlighterconfigurationsectionhandler, actiprosoftware.codehighlighter” />
</configsections>
httphandler的配置内容:
<httphandlers>
<add verb=”*” path=”*.asmx” type=”system.web.services.protocols.webservicehandlerfactory, system.web.services, version=1.0.5000.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a”
validate=”false” />
<add verb=”*” path=”error.aspx” type=”system.web.ui.pagehandlerfactory” />
<add verb=”*” path=”*” type=”dottext.common.urlmanager.urlrewritehandlerfactory,dottext.common” />
</httphandlers>
httpmodule的配置内容:
<httpmodules>
<add name=”urlrewritemodule” type=”dottext.common.urlmanager.urlrewritemodule, dottext.common” />
<add name=”eventhttpmodule” type=”dottext.framework.scheduledevents.eventhttpmodule, dottext.framework” />
</httpmodules>
见到一个陌生的项目首先打开它的配置文件看看，这是我的习惯:)
先看看一些重点的配置内容:
看完web.config中的上述内容熟悉asp.net运行机制的朋友就明白,dottext代码的运行顺序。在这里我再简单重复下
aspnet的内部运行机制(若有不熟悉的朋友请参阅<<asp.net famework深度历险>>这本书,它对做asp.net开发的朋友很有帮助)：
remote client request—->iis—->aspnet_isapi.dll–>aspnet_wp.exe–>httpruntime—>
httpmodule—>httphandler factory—>httphandler—>httphandler.processrequest()–>response client request
好了，题归正转，client request首先是被httpmodule截获。当我们请求.text的url：http://www.cnblogs.com/floerggyy/时，首先是
dottext.common.urlmanager命名空间下类urlrewritemodule的相关方法被调用。
(为什么会被类urlrewritemodule截获远程请求呢？上面httpmodule配置节的内容不是标明了吗？？？^_^
明知故问，那么为dottext.framework.scheduledevents命名空间下的类eventhttpmodule会不会截获远程请求？什么时候截获呢？
当然是按先来后顺序了，中国的优良传统都忘了!!!
(其实这样说也是不太准确的，这两个httpmodule确是按顺序执行的但在httpmodule里的一些事件中它们是交叉运行的，好了类eventhttpmodule
不在我们的计论范围内在下面的代码就不分析了，有对这块不明白的最好去看下上面推荐的那本书^_^)
3 、url重写，部分代码分析(这块涉及到众多自定义配置节、httpmodule、httphandler的综合应用所以要理顺还是有点麻烦的，要有一小点分析别人代码的耐心。个人认为)
类urlrewritemodule的方法
private void context_beginrequest(object sender, eventargs e){
//它是主要作用是根据请求匹配正则表达式来设置是否重写客户所请求的url(它默认是重写url)，注意这句代码urlhelper.setenableurlrewriting(context,false);
if(configprovider.instance().isaggregatesite){
httpcontext context = ((httpapplication)sender).context;
string path = context.request.path.tolower();
int iextrastuff = path.indexof(“.aspx”);
if(iextrastuff > -1 || path.indexof(“.”) == -1) {
if(iextrastuff > -1)
{
path = path.remove(iextrastuff+5,path.length – (iextrastuff+5));
}
path = regexapplication.replace(path,string.empty,1,0);
if(path == “” || path == “/” || regexpath.ismatch(path))
{
urlhelper.setenableurlrewriting(context,false);
}
}else if(context.request.path.tolower().indexof(“services”) > 0 && context.request.path.tolower().indexof(“.asmx”) > 0 )
{
if(alllowservice(context))
{
if(context.request.requesttype!=”post”)
{
string regexstr=@”/\w+/services/”;
string url=regex.replace(context.request.rawurl,regexstr,”/services/”,regexoptions.ignorecase);
context.rewritepath(url);
}
//string filename =context.request; //system.io.path.getfilename(context.request.path);
//context.rewritepath(“~/services/” + filename);
}else{
context.response.clear();
context.response.end();
}
}
}
httpmodule处理完后(这句话并不正确，在这里是这样的)进入httphandler factory,根据httphandler的配置内容我们可以马上找到这个类
urlrewritehandlerfactory它是处理重写url请求核心，在这里我详细分析下。
它实现了ihttphandlerfactory
(看注释就知道这个类是很重要的了)
httpmodule处理完后(这句话并不正确，在这里是这样的)进入httphandler factory,根据httphandler的配置内容我们可以马上找到这个类
urlrewritehandlerfactory它是处理重写url请求核心，在这里我详细分析下。
它实现了ihttphandlerfactory
(看注释就知道这个类是很重要的了)
using system;
using system.web;
using system.web.ui;
using system.text.regularexpressions;
using dottext.framework;
using dottext.framework.components;
using dottext.framework.configuration;
namespace dottext.common.urlmanager
{
/**//// <summary>
/// class responisble for figuring out which .text page to load. by default will load an array of dottext.urlmanager.httphanlder
/// from the blog.config file. this contains a list of regex patterns to match the current request to. it also allows caching of the
/// regex’s and types
/// </summary>
public class urlrewritehandlerfactory: ihttphandlerfactory
{
public urlrewritehandlerfactory(){} //nothing to do in the cnstr
//自定义虚方法从自定义配置节内容反序列化时构造httphandler
protected virtual httphandler[] gethttphandlers(httpcontext context)
{
return handlerconfiguration.instance().httphandlers;
}
/**//// <summary>
/// implementation of ihttphandlerfactory. by default, it will load an array of httphanlder (dottext.urlmanager.httphandler) from
/// the blog.config. this can be changed, by overrideing the gethttphandlers(httpcontext context) method.
/// </summary>
/// <param name=”context”>current httpcontext</param>
/// <param name=”requesttype”>request type (passed along to other ihttphandlerfactory’s)</param>
/// <param name=”url”>the current requested url. (passed along to other ihttphandlerfactory’s)</param>
/// <param name=”path”>the physical path of the current request. is not gaurenteed to exist (passed along to other ihttphandlerfactory’s)</param>
/// <returns>
/// returns an instance of ihttphandler either by loading an instance of ihttphandler or by returning an other
/// ihttphandlerfactory.gethanlder(httpcontext context, string requesttype, string url, string path) method
/// </returns>
//实现接口ihttphandlerfactory定义的方法
public virtual ihttphandler gethandler(httpcontext context, string requesttype, string url, string path)
{
//get the handlers to process. by defualt, we grab them from the blog.config
httphandler[] items = gethttphandlers(context);
//dottext.framework.logger.logmanager.log(“path”,dottext.framework.util.globals.removeappfrompath(context.request.path,context.request.applicationpath));
//do we have any?
if(items != null)
{
int count = items.length;
for(int i = 0; i<count; i++)
{
//we should use our own cached regex. this should limit the number of regex’s created
//and allows us to take advantage of regexoptons.compiled
//逐个匹配所配置节中定义的请求类型
if(items[i].ismatch(dottext.framework.util.globals.removeappfrompath(context.request.path,context.request.applicationpath)))
{
//注意这里是关键，注意返回的httphandler实例
//throw new exception();
switch(items[i].handlertype)
{
case handlertype.page://默认是page
return proccesshandlertypepage(items[i],context,requesttype,url);
case handlertype.direct:
handlerconfiguration.setcontrols(context,items[i].blogcontrols);
return (ihttphandler)items[i].instance();
case handlertype.factory:
//pass a long the request to a custom ihttphandlerfactory
return ((ihttphandlerfactory)items[i].instance()).gethandler(context,requesttype,url,path);
default:
throw new exception(“invalid handlertype: unknown”);
}
}
}
}
//if we do not find the page, just let asp.net take over
return pagehandlerfactory.gethandler(context,requesttype,url, path);
}
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;
}
public virtual void releasehandler(ihttphandler handler)
{
}
}
}
要注意它是如何把自定义配置节中的内容拈合成httphandler的实例
把这些理顺后对于理解.text的url重写就不难了….
对上面若有理解不正解的欢迎高手指正
