Git --NB Framework 中文教程
目录 ▾ 配置

最后更新于:2018-09-12 10:19
119次阅读0条评论

配置

NB的配置方式可能和大部分的php框架有所不同。
NB采用的是以类属性的方式来设置框架的相关参数。采用这样的方式是为了充分利用PHP类的一些特性,是配置更自由和更具扩展型。

配置类总是会在框架最开始运行时就被初始化,以单列的形式存在于程序的整个运行周期。

当然,NB也支持一种次要的业务配置,它是以数组的形式存在,这个会在下面讲解到。

本章节只讲怎么使用配置文件。
至于NB支持那些配置属性,会在讲到对应的功能的章节里面进行说明。

如何使用配置

NB的配置文件的位置并不强制,如果你不指定它的位置,框架默认读取项目根目录下的config.inc.php文件,如下面结构:

/home/www/demo/                      
├─application  
├─common                      
├─module                            
├─tmp                                
├─config.inc.php         框架配置目录
└─server                             

框架配置必须继承自nb\Config,如果没有指定,默认配置文件名必须为config.inc.php,配置类的类名必须为Config。
我们来编写一个默认位置的配置文件:

#path: home/www/demo/config.inc.php

class Config extends nb\Config {
    //开启调试
    public $debug      = true;
}

框架本身对几乎所有的设置都做了默认处理,所以你基本上可以配置文件里不写任何设置,也能运行。
如果我不想把配置文件放在根目录应该怎么处理?
比如将配置文件放在common目录下,此时不能使用config.inc.php作为文件名了,必须保持类名和文件名相同,比如取名为Configure,则有如下的结构:

/home/www/demo/                      
├─application                        
├─common               
│  └─Configure.php      框架配置目录                 
├─tmp                                
├─LICENSE.txt                        
├─README.md                          
└─server                             

其中Configure.php的里的代码如下:

注意命名空间。关于命名空间可以参考命名空间章节

namespace common;
use nb\Config;

class Configure extends Config {
    //开启调试
    public $debug      = true;
}

在我们的入口文件里,有这样一句代码\nb\Config::register(),此时我们修改一下:

\nb\Config::register('common\\Configure');

到此,框架已经可以读取这个配置文件了,同理,你任意的配置类,只要将其完整的命名空间传给register函数即可。通常建议没有特殊情况,使用默认的位置,便于共识和维护。

下面看看\nb\Config::register()的原型:

/**
 * 注册当前配置对象
 * @param null $config
 * @throws \ReflectionException
 */
public static function register($config=null)

//$config参数可以接受一个命名空间的字符串或者一个数组
//当$config有值时,就不会读取默认位置的配置了
\nb\Config::register([
    'debug'=>false
]);

特殊使用

因为配置类必须继承\nb\Config,而\nb\Config继承了nb\Access抽象类,所以可以在配置文件里用到Access的提供的特性。
比如有这样的一个场景,我们想自动在本地环境开启调试模式,在线上关闭调试模式,以免人工修改发生上线忘记关闭调试模式的问题。

namespace common;
use nb\Config;

class Configure extends Config {
    //开启调试
    //public $debug      = true;

    public function _debug() {
        $host = \nb\Request::ins()->host;
        if($host == 'demo.ol.cx') {
            return true;
        }
        return false;
    }
}

是的,我们的配置属性支持以函数形式,只要函数名为下划线加对应属性名就可以了,框架会自动把它的返回值作为设置属性的值。这一特性可以让我们根据一定条件得到不同的配置。

读取

程序在运行\nb\Config::register()之后,就会初始化一个配置类实例对象,并赋值给\nb\Config::$o公共静态属性。
所以通常我们可以这样读取我们设置的配置:

//获取调试配置的设置
nb\Config:$o->debug;

//或者这样
$conf = nb\Config:$o;
$conf['debug'];

//再或者这样获取
nb\Config::getx('debug');

getx函数的原型:

//再或者这样获取
public static function getx($name,$tmp=true)

修改

我们可以在程序运行中,对事先设置的配置做一些修改,但是需要注意,这些修改有可能并不能达到你想要的结果。
因为有些给组件的配置,在组件初始化时读取后就不会在读取配置了,这时即使你修改对应配置也无法影响相应的组件了。

修改配置的方式很简单,如下:

//关闭debug
nb\Config:$o->debug=false;

//或者这样
$conf = nb\Config:$o;
$conf['debug']=false;

//再或者这样获取
nb\Config::setx('debug',false);

因为配置类的属性是全局暴露的,有时为了安全,我们希望对某项配置修改时进行一下过滤,防止非法修改。
例如,我们有这样一个需求,不允许在除开发环境以外对debug属性进行修改:

namespace common;
use nb\Config;

class Configure extends Config {

    //读取debug属性
    public function _debug() {
        $host = \nb\Request::ins()->host;
        if($host == 'demo.ol.cx') {
            return true;
        }
        return false;
    }

    //修改debug属性
    //___debug函数生效的前提是不存在直接的`public $debug  = true;`设置
    public function ___debug($value) {
        $host = \nb\Request::ins()->host;
        if($host == 'demo.ol.cx') {
            //如果是开发环境,将$value作为debug的值
            return $value;
        }
        //如果不是开发环境,则保持原来的值
        return $this-debug;
    }
}

我们定义一个函数名为三个下划线加对应属性名的函数,也就是___debug.
这样,当我们对debug属性进行修改时,将直接调用___debug函数,它的返回值就是debug属性的值。
此时:

//关闭debug调试
nb\Config:$o->debug=true;

//当我们执行了上面一句代码时,再读取debug配置属性时
//将不再执行`_debug`函数
echo nb\Config:$o->debug;

通常情况下,只要执行了修改配置属性的代码后。
它们对应的_xxx函数都将无效,这是因为Access的特性所致,可以参考这里
此时如果想仍然要执行_debug属性,可以这样:

//不从缓存里读取
nb\Config::getx('debug',false);

如何使用业务配置

文章开头讲过NB也支持一种次要的业务配置。这种配置往往并不需要使用,但有些场景,还是很有用的。

业务配置文件存放的位置,默认为application/include/下,你可以在框架配置里通过path_autoinclude属性来修改,如下:

//默认是这样的配置
public $path_autoinclude    = [
    'application/include/'
];

//可以按照自己的需要进行修改,并且可以添加多条目录
public $path_autoinclude    = [
    'application/include/'
    'config/'
];

业务配置对文件名是有一定的要求的,通常情况下,NB会自动对目录下以.inc.php.fuc.php后戳的文件进行include,然后在根据框架配置里的path_autoext来include其它的配置文件,如下面配置:

public $path_autoext='qa';

该配置会include后戳为.qa.php的文件。这种设置是为了方便在不同的环境使用不同的配置。

NB为了防止项目上线时忘了修改path_autoext造成配置错误的问题,也支持下面这种配置:

public $path_autoext       = [
    'demo.nb.cx'=>'demo',
    'qa.nb.cx' =>'qa',
    'nb.cx' =>'live'
];

这种方式是根据每次请求的host来加在不同的配置文件,如项目的域名为nb.cx的时候就会include后戳为.live.php的文件,而为demo.nb.cx的时候,就会include后戳为.demo.php的文件。其它依次类推。

现在我们在demo/application/include目录下编写一个common.inc.php的配置文件,内容如下:

//这里可以定义一个常量
define('BASE_PATH','/home/www/uploads');

//这是标准的定义方式
$config['hello'] = 'world';

$config['mail'] = [
    'user'=>'xxx@qq.com'
    'pass'=>'123456'
];

在业务配置文件里,除了常量外,标准的配置都必须赋值给'$config'数组,否则将无法读取,且索引不要有重复,否则会覆盖。

读取业务配置

业务配置的读取,也是通过nb\Config类,如下:

//读取mail配置
$mail = nb\Config::get('mail');

//也可以通过助手函数来读取配置
$hello = conf('hello');

首先看一些\nb\Config提供的方法:

方法说明
register注册并初始化配置类对象
get获取业务配置的值
set设置业务配置的值
set_merge通过合并来修改业务配置的值
getx获取框架配置的值
setx设置框架配置的值
setx_merge通过合并来修改框架配置的值
load加载一个配置文件
import根据设置加载对应的文件

nb\Config属性和方法详解

属性

TODO

方法

TODO

上一篇:响应输出
下一篇:重定向

相关评论

您需要登录后才可以发表评论