层次配置体系
我们曾论及,服务器上可以有多个配置文件存在于不同的目录中。当对一个详细URL的请求到达时,ASP+计算该URL在层
次结构风格中的设定,并为所请求的URL使用在路径中定位的配置文件。
例如,一个站点的结构如下:
Application Root
|-----SubDir1
|-----SubDir2
想法是,配置应用程序的设定使所有的用户都可以访问应用程序根目录(Application Root),使选中的用户可以访问两
个子目录。
现在假定有一个Config.web文件在目录SubDir1中,Application Root和SubDir2中不存在Config.web文件。在此例中实
际上使用了两个Config.web文件。最高层的Config.web文件位于 %windir%ComplusVersion 目录,它随NGWS SDK安装而
来,包含了默认的设定。这个文件被认为处于机器级别上,所有的ASP+目录和子目录都继承了其设定。此文件的默认安全
小节的设定是允许所有用户的访问。当例中的Application Root目录不存在配置文件,即没有编辑这个设定值时,所有的
用户都将允许访问此目录,因为此目录继承了机器级别配置文件的设定。如果SubDir1目录中的Config.web文件包含了一个
安全配置小节,它设定成只允许某些用户访问目录,那么SubDir2目录将继承其设定,但是Application Root目录并不受其
影响。所以,所有的用户可以访问Application Root目录,但只有某些用户可以访问两个子目录。
标准配置设定
ASP+环境自带了一个标准的Config.web文件,它包含了一个丰富的配置设定集合。此文件位于
%windir%ComPlusVersion 目录。在Machine level(机器级)的配置文件中,我们可以在ASP+标准配置小节处理器下面找
到标准的配置小节。
SunADM@2K1020
--------------------------------------------------------------------------------
作 者:SunADM
我们曾论及,服务器上可以有多个配置文件存在于不同的目录中。当对一个详细URL的请求到达时,ASP+计算该URL在层
次结构风格中的设定,并为所请求的URL使用在路径中定位的配置文件。
例如,一个站点的结构如下:
Application Root
|-----SubDir1
|-----SubDir2
想法是,配置应用程序的设定使所有的用户都可以访问应用程序根目录(Application Root),使选中的用户可以访问两
个子目录。
现在假定有一个Config.web文件在目录SubDir1中,Application Root和SubDir2中不存在Config.web文件。在此例中实
际上使用了两个Config.web文件。最高层的Config.web文件位于 %windir%ComplusVersion 目录,它随NGWS SDK安装而
来,包含了默认的设定。这个文件被认为处于机器级别上,所有的ASP+目录和子目录都继承了其设定。此文件的默认安全
小节的设定是允许所有用户的访问。当例中的Application Root目录不存在配置文件,即没有编辑这个设定值时,所有的
用户都将允许访问此目录,因为此目录继承了机器级别配置文件的设定。如果SubDir1目录中的Config.web文件包含了一个
安全配置小节,它设定成只允许某些用户访问目录,那么SubDir2目录将继承其设定,但是Application Root目录并不受其
影响。所以,所有的用户可以访问Application Root目录,但只有某些用户可以访问两个子目录。
标准配置设定
ASP+环境自带了一个标准的Config.web文件,它包含了一个丰富的配置设定集合。此文件位于
%windir%ComPlusVersion 目录。在Machine level(机器级)的配置文件中,我们可以在ASP+标准配置小节处理器下面找
到标准的配置小节。
SunADM@2K1020
--------------------------------------------------------------------------------
作 者:SunADM