虽然SharePoint Server 2007使用了ASP.NET 2.0的基础页面模型,SharePoint页面基本上也是基于标准的aspx技术来构建,但SharePoint Server 2007的页面模型仍然要比普通的ASP.NET应用复杂很多。对于一个SharePoint开发人员(和设计人员),了解SharePoint的页面模型是非常非常重要的。
在SharePoint 2007中,将页面分为两种:Application Page和Site Page。Application Page是指SharePoint应用程序中用到的页面。比如,当我们进入到一个SharePoint站点的站点设置中后,几乎所有的站点设置页面都是Application Page。如果我们看到地址栏中的页面路径都是类似“http://sharepointsite/_layouts/xxx.aspx”这样的格式,也就是说,页面位于“_layouts”虚拟目录中,那么这个页面就是Applicatoin Page。Application Page在物理上被存放在SharePoint Web前端服务器的“Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts”目录中,不能被用户进行定制。而Site Page是指位于一个SharePoint站点中的普通页面。比如,站点的首页:“http://sharepointsite/default.aspx”,或者位于一个文档库中的页面:“http://sharepointsite/pages/xxx.aspx”,都是Site Page。
Application Page实际上和一个普通的ASP.NET页面没有任何区别。开发人员如果有需要,可以自己添加新的Application Page,你既可以在“Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts”目录中添加新的页面,也可以在这个目录下创建新的子目录(或虚拟目录),来放置你的Application Page。在Application Page中,开发人员可以根据自己的需求,直接添加In-line code,这些code都会直接被执行,就像一个普通的ASP.NET应用程序一样(当然,对于Code-behind的模式,Application Page也是支持的)。比如:
<script runat="server">
protected void Page_Load(Object sender, EventArgs e)
{
// 代码...
}
</script>
对于Application Page,SharePoint 2007总是认为它们是安全的,因为,站点的管理员(非服务器管理员)和用户都没有办法直接修改Application Page,所以,SharePoint 2007会直接“执行”它们。
如果你要创建自己的Application Page,尽量遵守这样的模式:
1、让你的Application Page从“Microsoft.SharePoint.WebControls.LayoutsPageBase”继承下来;
2、让你的Application Page使用位于Layouts目录中的“Application.master”这个Master Page;
3、在Layouts目录中创建一个新的子目录(或虚拟目录)来放你的Application Page,不要和SharePoint自带的Application Page混杂在一起。
Site Page比Application Page要更复杂一些。对于Site Page,我们通常根据它们是否已经被进行了定制(通过SharePoint Designer 2007),将Site Page分为Uncustomized Page和Customized Page。(在SPS2003中,使用的是Ghosted Page和Unghosted Page这两个术语。)
当我们新建一个站点的时候,所有的页面都是Uncustomized Page,这些页面都是直接使用了存放在SharePoint Web前端服务器磁盘上的页面模板(位于“Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE”的各个子目录中),换言之,这个新站点的页面其实是“不存在的”,它们只是一个“标记”(这也就是在SPS2003中,它们被称为Ghosted Page的原因),如果用户访问一个页面,SharePoint会自动从磁盘上找到那个真正的页面模板文件,然后将其载入到内存中,解析它,并将其编译成一个独立的dll文件(为了性能,这个dll会缓存在磁盘上以避免下次重复编译),然后载入这个dll,运行,输出。
但是,如果站点设计人员用SharePoint Designer 2007打开这个SharePoint站点,然后用SharePoint Designer打开某个Site Page文件,进行某些修改,保存,SharePoint会自动将修改后的文件内容保存到站点所用的内容数据库中,它就成了一个Customized Page。从此,这个Customized Page就和磁盘上的页面模板“脱离关系”了。当用户访问这个页面时,SharePoint会自动从内容数据库中读出这个文件的内容,然后对其进行解析,运行。注意!这次,SharePoint不会再将其编译成一个独立的dll文件了,实际上,SharePoint会在内存中载入这个页面的结构,运行,然后输出,然后将它从内存中卸载以节省内存。
从Uncustomized Page和Customized Page的运行模式上,我们就能看出它们的运行效率存在着不小的差别。首先,Uncustomized Page是位于磁盘上的,它的读入速度会比较快,其次,Uncustomized Page会在第一次被访问时就被编译成一个dll,避免了重复编译。比如,两个不同SharePoint站点的首页“default.aspx”如果都是Uncustomized Page,而且使用的是同一个页面模板,它们只会被编译一次。而Customized Page位于内容数据库中,读入速度比不上磁盘文件,而且它不会被编译成dll,而是只会在内存中进行解析,运行。
但是,有意思的是,Customized Page的解析运行方式虽然在速度上可能要慢,但却要更节省内存一些。因为在内存中载入一个页面的结构,进行解析运行后,是可以再释放掉的,而一个dll被载入后,是不能被释放掉的。这是因为.NET不支持载入程序集后再卸载程序集,呵呵。(但.NET支持创建AppDomain后再释放掉AppDomain。)
除了存放位置和运行效率上的不同,在代码安全上,Uncustomized Page和Customized Page也存在很大的区别。
类似于Applicaton Page,Uncustomized Page也是被SharePoint信任的页面,位于Uncustomized Page里面的ASP.NET In-line code会被直接运行。而Customized Page由于可以被站点设计者(可能他并非是服务器管理员)通过SharePoint Designer向其中加任意的In-line code,所以,默认的安全规则根本不会允许Customized Page中的服务器端代码被运行。
类似的,如果Uncustomized Page上面被放置一个服务器端控件,是没有问题的,但是,如果要向Customized Page上放一个服务器端控件(包括Web Part),那么这个控件就必须在站点的web.config中被标识为“Safe Control”(也就是增加新的“<SafeControl>”节点来标识某个控件是安全的)。
虽然SharePoint对Customized Page有这些安全上的限制,但是,服务器管理员通过修改web.config文件中的安全设置,是可以更改这样的默认安全限制的。比如,如果你希望站点的“MyPages”目录下的页面,即使它们是Customized Page,也允许被包含服务器端In-line code,可以在web.config中增加这样的内容:
<SharePoint>
<SafeMode ...>
<PageParserPaths>
<PageParserPath VirtualPath="/MyPages/*" CompilationMode="Always"
AllowServerSideScript="true" AllowUnsafeControl="true" IncludeSubFolders="true"/>
</PageParserPaths>
“CompilationMode”节点的值可以是:Never、Always和Auto,将其设置为Always,就可以强制进行编译。“AllowServerSideScript”是指定是否允许服务器端的代码,“AllowUnsafeControl”是指定是否允许非安全(也就是没有在“SafeControls”区域指定为安全)的控件。
最后要提醒的是,虽然通过修改web.config中的设置可以让所有的Site Page都能包含服务器端代码,但如非必要,尽量不要这样做。因为这将会使有权限对站点进行设计的人,通过使用SharePoint Designer,就可以在任何页面中添加In-line code,来进行任何操作。
SharePoint SDK参考: