SharePoint基础之九- Site Page与Application Page
在一个WSS站点中的某些页面, 比如说首页(default.aspx), 支持用户使用SharePoint Designer这样的工具进行定制化(customization). 支持定制化的页面叫做site pages. 虽然对于定制化提供支持的site page提供了很大程度上的灵活性, 可是它也有不利的一面. 为了支持页面定制化而不相反地影响可伸缩性, WSS必须使用前面讨论过的page ghosting. 但是页面的定制化还是会可伸缩性有相当程度的影响.
想象某个具有一个运行着上千个站点的Web Application这样的WSS环境吧. 如果每个站点的管理员都使用SharePoint Designer更改了站点的首页, 那么会发生什么? 这些站点里的每一个页面都会变成unghosted. 这就会通过强制前端服务器去分别地从内容数据库中取回每一个页面, 从而消极地影响可伸缩性. 每一个页面都会不得不各自地经过解析然后加载到内存中.
再来考虑一个事实, 当一个站点页面被定制化过了, 一个拷贝就一定会存在内容数据库中. 这就带来了一个安全问题. 想象有这样一个情形, 一个恶意用户被赋予了站点集的管理员权限, 他试图通过在一个自定义版本的站点页面中写内联代码来进行攻击. 这个安全问题被WSS的一个默认的策略搞定了, 这个策略是: 禁止site page中包含inline代码. 这个默认策略还使得site page在非编译模式下运行, 也就是说他们不会被编译为DLL.
这里的关键点在于对于site page的定制化的支持带来了性能问题和安全问题. 如同稍早时候注意到的, WSS架构提供了另一种类型的页面, 叫做application page. application page的一个关键特性是: 它不支持定制化. 所以application page可以绕过与site page相关联的性能问题和安全问题.
标准的站点配置页面(settings.aspx)是一个application page的好例子. 它可以在任意的站点内被访问, 而且他不支持定制化. Application Page, 比如说settings.aspx, 作为物理文件被部署在Web前端服务器的文件系统上, 部署在下面的路径中:
c:\program files\common files\microsoft shared \web server extensions\12\TEMPLATE\LAYOUTS
注意, 每次WSS创建一个Web application, 物理路径\LAYOUTS目录就被映射到虚拟路径_layouts上. 使用这种映射机制, 再加上一些额外的处理逻辑, WSS运行时可以使得任何一个application page在任何站点的上下文中, 被访问到. 比如说, 假设现在有如下的三个不同的站点, 他们在WSS场环境中可以通过如下的三个URL访问:
-
http://Litwareinc.com
-
http://Litwareinc.com/sites/Vendors
-
http://Litwareinc.com:1001/sites/Accounting
An application page, such as settings.aspx, can be accessed by adding its relative path within the _layouts directory to the end of a site’s URL. For example, you can access the Site Setting page by using any of the following three URLs:
一个application page, 比如说settings.aspx, 可以通过在站点URL后添加它在_layouts文件夹中的相对路径来访问. 比如说, 你可以通过如下的URL来访问站点的Settings.aspx.
-
http://Litwareinc.com/_layouts/settings.aspx
-
http://Litwareinc.com/sites/Vendors/_layouts/settings.aspx
-
http://Litwareinc.com:1001/sites/Accounting/_layouts/settings.aspx
因为在场水平上, 一个Application Page就只有一个版本, 所以它可以被编译成为一个单个的DLL, 然后每个web application仅一次地加载到内存中. 你永远不需要担心在不同站点上有不同版本的application page. 更进一步地, application page并不会受拥有定制化权限的用户的攻击. 所以WSS并不阻止他们中包含内联代码(in-line code).
Application page被WSS团队广泛地应用来支持用于创建和管理站点以及站点内部元素的许多功能. 下图表现了\LAYOUTS物理文件夹的一个图片. 你可以看到WSS3.0的标准安装包括了许多不同的application page, 包括settings.aspx
如果随便打开并且查看标准的WSS的一个application page, 你会看到它链接到一个在_layouts目录下的母版页, 叫做application.master. 后面的部分, 我们会介绍创建自定义的application page. 当你创建一个自己的application page的时候, 你可能想要跟从它们, 一样也连接到application.master.
现在让我们总结一下site page和application page的不同之处吧. site page支持页面定制化. 比如说首页, 还有跟列表和文档库关联的其他页面, 比如说AllItems.aspx, NewForm.aspx, 和EditForm.aspx. 事实上site page支持定制化提供了定制化, 但也会影响到性能和可伸缩性. site page不支持内联代码, 由于WSS强制执行了一个默认的安全策略.
Application Page不支持定制化, 这也提供给了他两个优于site page的地方. 首先, 任何一个application page都会被编译为一个单个的DLL文件, 所以他们的性能和可伸缩性都要比site page好. 第二, application页面允许包含内联代码.