网站前端建设都需要什么问题,我的网站是面向全国的选哪个公司的服务器比较好,网站架设地址,政务网站建设模块Microsoft SharePoint Foundation 中主要有两种类型的页面#xff0c;分别是应用程序页(Application Page) 和网站页(Site Page)。 应用程序页(Application Page) 和网站页(Site Page)都从同一母版页继承其布局。 应用程序页(Application Page)与传统的 Microsoft ASP.NET 3.5…Microsoft SharePoint Foundation 中主要有两种类型的页面分别是应用程序页(Application Page) 和网站页(Site Page)。 应用程序页(Application Page) 和网站页(Site Page)都从同一母版页继承其布局。 应用程序页(Application Page)与传统的 Microsoft ASP.NET 3.5 网页最为相似。但是应用程序页面并非直接派生自System.Web.UI.Page而是派生自 LayoutsPageBase 或 UnsecuredLayoutsPageBase。应用程序页面不在安全模式下运行并且可能包含内嵌代码。只有场管理员可以安装应用程序页面。 网站页(Site Page)是由最终用户创建、编辑和自定义的页面是可以由用户个性化定制与修改的页面。网站页是通过存储在前端 Web 服务器Front-End Web Server的文件系统上的模板页面设置的。在设置网站时SharePoint Foundation 会创建指向文件系统上的页面模板实例的指针这个指针存放在使用了此网站页的Website的Content Database中。这样SharePoint Foundation 就可以避免重复创建每次创建网站时都要设置的页面的副本。 网站页(Site Page)具有两种类型 - 标准页(Standard Page)和 Web 部件页(Web Part Page)。 标准页(Standard Page)包含文本、图像、Web 部件及其他元素。这些页面是启用 wiki 的页面可以包含 Web 控件和内嵌 Web 部件。标准页(Standard Page)派生自 WikiEditPage 类而不直接派生自 System.Web.UI.Page。 Web 部件页(Web Part Page) 顾名思义它们是包含 Web 部件区域(Web Part Zone)的 Web 部件(Web Part)页。Web 部件页(Web Part Page)派生自 WebPartPage而不直接派生自 System.Web.UI.Page。 Sharepoint2010中加入了第三种网站页Site PagePublishingPage这种页面只使用在发布网站(Publishing Sites)中。在发布网站中作者和批准者(Author and Approvers)使用发布功能(Publishing Feature)来创建内容以提供给网站用户访问。通常来说一个发布网站都会绑定有Approval工作流这样待发布的内容才能在正式发布前把握质量。Publishing Pages通常基于Page layouts这样的页面模板创建Page Layouts提供了一致性的结构给Publishing Pages并且它是可以被客户化定制的。 Sharepoint还包括一套内建的用于移动设备的网页。SharePoint Foundation 移动网页比非移动网页简单得多。移动网页不使用 ASP.NET 母版页/内容页技术也不划分为应用程序页面和网站页面。SharePoint Foundation 移动网页都是应用程序页面且位于 \_layouts\Mobile 文件夹中。SharePoint Foundation 移动网页在某个方面特别类似网站页面如果页面包含移动的 Web 部件适配器则必须将该适配器注册为安全控件否则将不呈现该适配器
上面对Sharepoint的网页情况作了大致说明
下面让我们来重点比较一下应用程序页(Application Page)与网站页(Site Page)看看它们具体的区别:
1、应用目的(Typical purpose): 应用程序页( Application pages)侧重于功能实现function-oriented比如象提供给用户的用于创建一个新的Web Application的页面那就是应用程序页你在那个创建页面上输入所需的参数然后再点确定从而创建一个新的Web Application。 而网站页Site Pages则侧重于内容实现Content-oriented比如像在标准的Team Site中给用户展示当前网站都有哪些list的页面就是网站页。 当然这种区分并不是强制性的有时也有混用的情况第三方可以开发一个用户定义的Web Part在这个Web Part上实现一些特定的用户操作功能(eg:List管理功能信息处理功能…就像你一般的应用程序处理界面上的那些功能一样)然后再把这个Web Part加载到网站页从而让网站页也具有了功能操作性。有时这种方式比开发一个应用程序页更灵活也更便捷。
2、用户定制能力(Customizability): 网站的所有者(owner)以及拥有相应权限的用户可以对网站页(Site Page)进行用户定制修改用户还可以添加一个新的ASCX页面到网站页陈列区Site Pages Gallery。 但用户却无权对应用程序页(Application Page)进行定制与修改只有管理员才有权限安装一个新的应用程序页到网站上来。
3、继承基类(Class inheritance): 应用程序页( Application pages)继承自 LayoutsPageBase 类 或者UnsecuredLayoutsPageBase 类。 网站页site pages继承自 WikiEditPage 类或 WebPartPage 类. 而所有上面提到的基类又都继承自ASP.NET的 Page 类.
4、Web 部件支持(Web Part support): 应用程序页( Application pages)没有Web Part Zone或者动态的Web Parts但它可包含静态的Web Parts可这种静态的Web Parts没多少实用价值因为开发者完全可以采用传统控件来实现要在此页面上完成的功能。 网站页Site pages既可以包含静态Web Parts也可以包含动态Web Parts和Web Part Zone。
5、存储位置(Storage location): 应用程序页( Application pages)存储在前端Web服务器(Front-End Web Server)的文件系统上其位置是在对应的Web Application的_Layouts虚拟目录(Virtual Directory)下,此虚拟目录会映射到(Map to)服务器文件系统的实际磁盘目录上此目录是 :%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS 目录或其子目录。 网站页(Site Page)通常根据它们是否已经被进行了定制来分为Uncustomized Page和Customized Page两种在SPS2003中使用的是Ghosted Page和Unghosted Page这两个术语,具体说明如下 I、网站页没有被客户个性化定制修改当我们新建一个站点的时候所有的页面都是Uncustomized Page这些页面都是直接使用了存放在前端 Web 服务器Front-End Web Server磁盘上的页面模板位于%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE目录及其子目录(eg: SiteTemplates与Features子目录就是常用的子目录)换言之这个新站点的页面其实是不存在的它们只是一个标记这也就是在SPS2003中它们被称为Ghosted Page的原因如果用户访问一个页面SharePoint会自动从磁盘上找到那个真正的页面模板文件然后将其载入到内存中解析它并将其编译成一个独立的DLL文件为了性能这个DLL会缓存在磁盘上以避免下次重复编译然后载入这个DLL并运行和输出. II、网站页被个性化定制或修改一旦网站页被Microsoft SharePoint Designer这样的工具修改那么SharePoint会自动将修改后的文件内容保存到站点所用的内容数据库(Content Database)中它就成了一个Customized Page。当用户访问这个页面时SharePoint会自动从内容数据库中读出这个文件的内容然后对其进行解析运行。这种情况下SharePoint不会再将其编译成一个独立的DLL文件实际上SharePoint会在内存中载入这个页面的结构运行然后输出然后将它从内存中卸载以节省内存。 注Uncustomized Site Page虽然存放在文件系统中但实际上它在Content Database中也会有记录这个记录主要用于保存.aspx页面文件的存放路径这就是指向文件系统上的页面模板实例的指针。为什么会这么做呢那是因为Uncustomized Site Page通常会被若干个Website共享所以凡是调用到此Uncustomized Site Page的Website就会在它们的Content Database中存放此Page的路径。例如每一个Team Site的Content Database都会有记录指向Team Site的Home Page这个HomePage就是Uncustomized Site Page当打开TeamSite的相关网页时系统就会根据此处存放的HomePage的路径把HomePage调取并显示出来。当然如果有网站对此HomePage进行了个性化的修改那么它会变成了Customized Page于是相关修改内容就会保存进Content Database而原先Content Database中保存的路径记录就会被移除。不过可以通过 Web 浏览器或 SharePoint Designer 之类的工具将自定义页面重置为原始模板页面即放弃用户的个性化定制重新使用以前的页面模板这样一来在Content Database中又会重新存放指向文件系统上的页面模板实例的指针记录。 有的时候Uncustomized Site Page会被做为模板(Page Template)被存放在Content Database中的页面实例所引用。总之记住只要网站上的页面没有被个性化定制或修改那么放在Content Database中的记录就只是一个路径指针用于指向这个页面在文件系统中的存放路径的。
6、可访问性(Availability): 一个应用程序页(Application Page)可以被其所在的WebApplication中的任何Website访问到。 而一个网站页(Site Page)通常却只能被它所部署的网站中的用户访问到虽然我们前面提到Uncustomized site pages也可以被多个Website访问到但这需要特定的手段才能做到那些网站需要被做为Feature的一部分或Site Definition的一部分提供出来。
7、解析模式(Parsing mode): 应用程序页(Application Page)通过直接(Direct)方式进行解析。所谓直接方式就是指通过标准的ASP.NET页面解析器进行解析当这个网页首次被访问时它就会被解析器解析(Parsed)、编译(Compiled)并缓存在前端 Web 服务器Front-End Web Server的内存中直到此请求所关联的application domain或IIS被回收清空(recycled)。如果在回收前有其它访问请求那么它就会直接从缓存中提供给请求者而无需重新进行解析、编译的过程。 网站页(Site Page)分两种情况 I、Uncustomized site pages也是通过直接(Direct)方式进行解析。 II、而customized site pages与添加到陈列区(Site Page Gallery)的新建网页则是通过安全模式(Safe Mode)进行解析的。 安全模式(Safe Mode)解析特点如下: (i)、只有在Web Application的Web.config文件中注册为安全(Safe)的控件(包括Web Parts)才能被解析和呈现。 (ii)、内联服务器端代码(Inline server-side code)在安全模式下是不允许的如果你在网页中嵌入了内联服务器端代码那么系统会返回给你一个报错页面。 所谓内联服务器端代码如下:
script runatserver [code is here] /script 或 asp:button OnClickMyButtonHandler() / 对于后台代码(Code behind)和内嵌的JavaScript(embedded Javascript)是被允许的因为它会被编译成单独的程序集并部署。 (iii)、这种Customized Site Page网页与直接模式处理的应用程序页是不同的因为它不像应用程序页一样需要被系统编译因此如果在此类网页中加入诸如编译指令之类的东西都是不起作用的。 需要注明的是这里的安全模式解析(safe mode parsing)与Sharepoint其它文档提到的安全模式处理(safe mode processing)和安全模式呈现(safe mode rendering)其实指的都是同一件事。 Sharepoint为什么会引入这种安全模式呢? 你可以想想既然允许用户个性化定制那么就必须涉及到网页行为的定制由此产生的问题就是用户可能在个性化过程中加入执行代码如果这些代码既安全又高效那也没什么但谁又能保证所有用户都做到这点呢。还有就是这种网页不能被编译这也不难理解试想如果有成百上千个用户都做了个性化定制而这种个性化定制的网页都必须要通过重新编译才能呈现那么我们的服务器将承受多大的压力并且这些被编译的结果要放到服务器内存中缓存这个缓存的内容只能通过回收application domain来清除但问题是回收application domain就会清空程序集程序集中还包括了其它网页内容你做不到仅仅清空你想要移除的那个特定用户定制的网页要么都清空要么都保留这显然是不合理的。此外在一个application domain中可以加载多少个程序集在系统中也是有限制的。所以所有这些因素都决定了为什么Sharepoint会引入安全模式解析并且此解析方式为什么要按如此的规则开展工作。 我们在前面提到内联服务器端代码(Inline server-side code)在安全模式Safe Mode解析下是不允许的其实准确的说应该是在通常情况下是不允许的。其实Sharepoint也不是那么绝情它也留得有退路它允许你通过修改Web Application的Web.config来实现允许内联服务器端代码或不安全控件也即向Web.config中的Sharepoint节点下的SafeMode元素中添加PageParserPath子元素通过设置此元素的相关属性来指明要向哪个网页中添加内联服务器端代码或非安全控件(unsafe contrl)。显然这样作是比较危险的所以你必须要非常小心,因为这种解禁可以是单个特定页面也可以是整个目录的页面。添加 PageParserPath 设置将使可将页面上载到指定文件夹的任何人都能将任意的完全信任代码写入服务器。所以管理员在提供这些设置时应格外小心要提前了解此操作存在的安全隐患尽量保证系统的安全与性能。 一种威胁的例子 如果你允许所有以 GetInfo*.aspx模式命名的网页添加内联服务器端代码那么别有用心者就会个性化一个攻击性网页并以GetInfoAsMyMind.aspx来命名此命名当然能通过Sharepoint的查检规则并获得运行相关代码的权力结果就是对你的系统进行攻击与伤害。 下面的示例演示使用通配符的 PageParserPath 设置。 添加此 PageParserPath 将允许对母版页样式库具有权限的任何人上载服务器端代码。在添加此类型的 PageParserPath 设置时要格外小心。
SharePoint SafeMode ... PageParserPaths PageParserPath VirtualPath/_mpg/* CompilationModeAlways AllowServerSideScripttrue IncludeSubFolderstrue/ /PageParserPaths 至于非安全控件(Unsafe control)是指通过编辑工具(Editing Tool)添加的控件如通过Sharepoint Designer添加的控件。而至于WebPart则不管使没使用PageParserPath元素来开启(enable)非安全控件(Unsafe Control)都必须要注册为安全才能被允许。 你还可以通过使用PageParserPath元素来开启允许用户定制网站页(Customized Site Page)的可编译功能。这样这个网页就会被编译成DLL并存放到缓存中显然这种做法就类似于应用程序页(Application Page)的编译方式了这样做的好处就是加快此网页的访问响应速度。所以它只针对那些经常会被访问到的网页有效。
