CI框架源码阅读笔记7 配置管理组件 Config.php,ciconfig.php
CI框架源码阅读笔记7 配置管理组件 Config.php,ciconfig.php
一个灵活可控的应用程序中,必然会存在大量的可控参数(我们称为配置),例如在CI的主配置文件中(这里指Application/Config/Config.php文件),有如下多项配置:
<span>$config</span>['base_url'] = 'http://test.xq.com'<span>; </span><span>$config</span>['index_page'] = ''<span>; </span><span>$config</span>['uri_protocol'] = 'AUTO'<span>; </span><span>$config</span>['url_suffix'] = '.html'<span>; </span><span>$config</span>['language'] = 'english'<span>; </span><span>$config</span>['charset'] = 'UTF-8'<span>; </span><span>$config</span>['enable_hooks'] = <span>FALSE</span><span>; …………………………</span>
不仅如此,CI还允许你将配置参数放到主配置文件之外。例如,你可以定义自己的配置文件为Config_app.php, 然后在你的应用程序控制器中这样加载你的配置文件:
<span>$this</span>->config->load('config_app');
如此纷繁多样的配置项和配置文件,CI是如何进行管理的?这便是我们今天要跟踪的内容:CI的配置管理组件-Config.php.
先看该组件的类图:
其中:
_config_paths:要搜索的配置文件的路径,这里指APPPATH目录,你的配置文件也应该位于APPPATH下。
Config: 这个数组用于存放所有的配置项的item
Is_loaded: 存放所有的已经加载的配置文件列表。
_construct: 组件的构造函数,主要是配置base_url
_assign_to_config: 允许index.php中的配置项覆盖主配置文件中的设置
_uri_string,site_url,base_url,system_url: URI, 项目路径等相关处理。
load: 加载配置文件。
item:获取配置项
slash_item:同item,不同的是,在最后加了”\”分隔符,一般只有site_url,base_url等会需要slash_item
下面我们去剖析各个方法的具体实现:
1. 组件初始化 _construct
之前我们在分析Common.php全局函数的时候提到过,在Config组件实例化之前,所有的组配置文件的获取都是由get_config()函数来代理的。在Config组件实例化时,要将所有的配置存放到自己的私有变量$config中,便于之后的访问和处理:
$this->config =& get_config();
由于我们应用程序很多时候需要获取base_url的值,而这个值并不是必填项(config中base_url可以设置为空),但我们又不希望获取到的base_url的值为空。因此,CI在Config组件初始化的时候,对base_url做了一定的处理。这主要出现在Config.php中base_url设置为空的情况:
(1). 如果设置了$_SERVER[‘HTTP_HOST’],则base_url被设置为Protocal(http或者https) + $_SERVER['HTTP_HOST'] + SCIRPT_PATH的形式:
$base_url = isset($_SERVER['HTTPS']) && strtolower($_SERVER['HTTPS']) !== 'off' ? 'https' : 'http'; $base_url .= '://'. $_SERVER['HTTP_HOST']; $base_url .= str_replace(basename($_SERVER['SCRIPT_NAME']), '', $_SERVER['SCRIPT_NAME']);
(2). 否者,直接被设置为http://localhost/:
$base_url = 'http://localhost/';
(3). 同时将base_url配置项映射到配置数组中,方便之后的访问(set_item方法我们稍后会将,这里只需要知道,它是添加到配置项且会覆盖旧值):
$this->set_item('base_url', $base_url);
之后我们会看到,base_url这个配置项对于很多组件都是必须的,因此,CI花费一定的精力来保证base_url的正确性,也是可以理解的。
2. 加载配置文件 load
这是Config组件中较核心的方法之一,该函数的签名:
<span>function</span> load(<span>$file</span> = '', <span>$use_sections</span> = <span>FALSE</span>, <span>$fail_gracefully</span> = <span>FALSE</span>)
所有的参数都是可选参数。
我们这里简单解释一下各形参的含义:
$file 需要加载的配置文件,可以包含后缀名也不可以不包含,如果未指定该参数,则默认加载Config.php文件
$user_sections: 是否为加载的配置文件使用独立的section,这么说可能还是不明白,试想,如果你定义了自己的配置文件,而你的配置文件中的配置项可能与Config.php文件中的配置项冲突,通过指定$section为true可以防止配置项的覆盖。
$fail_gracefully: 要load的配置文件不存在时的处理。Gracefully意为优雅的,如果该参数设置为true,则在文件不存在时只会返回false,而不会显示错误。
下面看该方法的具体实现:
(1). 配置文件名预处理:
<span>$file</span> = (<span>$file</span> == '') ? 'config' : <span>str_replace</span>('.php', '', <span>$file</span>);
这个$file最后只包含文件名,而不包含扩展名。如果该参数为空,则默认加载Config.php配置文件。这同时也说明,我们加载自己的配置文件时:
$this->config->load("");与
$this->config->load("config")效果是一样的,而:
$this->config->load("config_app")与
$this->config->load("config_app.php")的效果也是一样的。
如果启用了$use_sections,这个$file会作为config的主键。
(2). 查找和加载配置文件。
在跟踪实现之前,先解释几个查找和加载过程中比较重要的参数:
(3).具体的查找过程是一个双重的foreach循环:
/* 对于config_paths中的路径循环查找 */ foreach ($this->_config_paths as $path) { /* 对每个location查找,也就是分别对ENVIRONMENT/config/ 和 config/ 目录查找 */ foreach ($check_locations as $location) { /* 实际的配置文件名 */ $file_path = $path.'config/'.$location.'.php'; <br /> /* 如果已经加载,则跳至最外层循环,事实上,由于_config_paths的设定,会跳出整个循环 */ if (in_array($file_path, $this->is_loaded, TRUE)) { $loaded = TRUE; continue 2; } /* 若文件存在,跳出当前循环 */ if (file_exists($file_path)) { $found = TRUE; break; } } /* 如果没有找到配置文件,继续下一次循环。同样,由于_config_path的设定,会跳出整个循环 */ if ($found === FALSE) { continue; } }
(4).引入配置文件
到这里,如果配置文件不存在,则$found和$loaded都为false,CI会根据fail_gracefully参数决定文件不存在的处理方式;如果文件存在,则需要对配置文件的格式检查:
/* 引入配置文件 */ include($file_path); /* 配置文件的格式检查,这同时也说明,配置文件中最起码应该包含$config数组 */ if ( ! isset($config) OR ! is_array($config)) { if ($fail_gracefully === TRUE) { return FALSE; } show_error('Your '.$file_path.' file does not appear to contain a valid configuration array.'); }
(5).对use_sections参数的处理
前面说过,use_secitons参数如果为true,则CI_Config会对该配置文件启用独立的key存储。例如,我们在controller中这样加载配置文件:
<span>$this</span>->config->load("config_app",<span>true</span>);
则config数组是这样的格式:
[config] => <span>Array</span><span> ( [base_url] </span>=> http:<span>//</span><span>test.xq.com</span> [index_page] =><span> [uri_protocol] </span>=><span> AUTO [url_suffix] </span>=> .<span>html [proxy_ips] </span>=><span> [web_akey] </span>=><span> yyyyyyyyyyyy [config_app] </span>=> <span>Array</span><span> ( [web_akey] </span>=><span> xxxxxxx [web_skey] </span>=><span> xxxxxxxxxxxxxxxxxxx [web_callback_url] </span>=> http:<span>//</span><span>test.xq.com/</span> [sess_pre] =><span> WEB_APP [cart_min] </span>=> 1<span> [cart_max] </span>=> 999<span> ) )</span>
相反,如果我们不指定use_sections,则数组是这样存储的:
[config] => <span>Array</span><span> ( [base_url] </span>=> http:<span>//</span><span>test.xq.com</span> [index_page] =><span> [uri_protocol] </span>=><span> AUTO [url_suffix] </span>=> .<span>html [web_akey] </span>=><span> xxxxxxx [web_skey] </span>=><span> xxxxxxxxxxxxxxxxxxx [web_callback_url] </span>=> http:<span>//</span><span>test.xq.com/</span> [sess_pre] =><span> WEB_APP [cart_min] </span>=> 1<span> [cart_max] </span>=> 999<span> )</span>
这也意味着,在不启用user_secitons的情况下,如果你的配置文件中有与主配置文件Config.php相同的键,则会覆盖主配置文件中的项:
/* 启用单独的key存放加载的config */ if ($use_sections === TRUE) { if (isset($this->config[$file])) { $this->config[$file] = array_merge($this->config[$file], $config); } else { $this->config[$file] = $config; } } else { /* 执行merge,更改CI_Config::config */ $this->config = array_merge($this->config, $config); }
(6).错误处理
双层循环完成后,如果loaded为false,也就是未成功加载任何配置,则根据fail_gracefully做相应的错误处理:
/* 未成功加载任何配置 */ if ($loaded === FALSE) { if ($fail_gracefully === TRUE) { return FALSE; } show_error('The configuration file '.$file.'.php does not exist.'); }
3. 获取配置项item,slash_item
item方法用于在配置中获取特定的配置项,改方法的签名:
<span>function</span> item(<span>$item</span>, <span>$index</span> = '')
注意,如果你在load配置文件的时候启用了use-sections,则在使用item()获取配置项的时候需要指定第二个参数,也就是加载的配置文件的文件名(不包含后缀)。为了更清楚这一点,我们假设现在Config/目录下有配个配置文件:config.php和config_app.php,这两个配置文件中含有一个相同的键web_akey, 在config.php中,该配置为:
<span>$config</span>['web_akey'] = 'yyyyyyyyyyyy';
而config_app.php中,该配置为:
<span>$config</span>['web_akey'] = 'xxxxxxx';
现在,通过use-sections的方法加载config_app配置文件(config.php会在Config组件初始化的时候被加载):
$this->config->load("config_app",true);
然后在控制器中获取web_akey配置项:
echo "config_app:web_akey => ",$this->config->item("web_akey","config_app"),"<br/>"; echo "config :web_akey => ",$this->config->item("web_akey");
实际的获取结果:
config_app:web_akey =><span> xxxxxxx config </span>:web_akey => yyyyyyyyyyyy
了解原理之后,该方法的实现就比较简单了:
function item($item, $index = '') { /* 没有设置use_sections的情况,直接在config中寻找配置项 */ if ($index == '') { if ( ! isset($this->config[$item])) { return FALSE; } $pref = $this->config[$item]; } else { if ( ! isset($this->config[$index])) { return FALSE; } if ( ! isset($this->config[$index][$item])) { return FALSE; } $pref = $this->config[$index][$item]; } /* 统一的return出口 */ return $pref; }
slash_item实际上与item()方法类似,但他不会去用户的配置中寻找,并且,他返回的是主配置文件中的配置项,并在配置项最后添加反斜杠.这个方法,通常用于base_url和index_page这两个配置项的处理:
该方法的实现源码:
function slash_item($item) { /* 不存在配置项 */ if ( ! isset($this->config[$item])) { return FALSE; } /* 配置项为空 */ if( trim($this->config[$item]) == '') { return ''; } /* 去除最后的多余的"/",并在结尾添加一个"/" */ return rtrim($this->config[$item], '/').'/'; }
4. 获取站点site_url, base_url,system_url
这里先澄清这几个含义的区别:
echo "site_url : ",$this->config->site_url("index/rain"),"</br>"; echo "base_url : ",$this->config->base_url("index/rain"),"<br/>"; echo "system_url: ",$this->config->system_url();
的结果分别是:
<span>site_url : http://test.xq.com/index/rain.html base_url : http://test.xq.com/index/rain system_url: http://test.xq.com/system/</span>
可以看出,site_url是添加了suffix(在Config/config.php中配置)后的url地址(呵呵,如果你的uri中有query string,则Ci总是在最后添加suffix:http://test.xq.com/index/rain?w=ss.html 是不是很奇怪.)
base_url则是没有添加suffix的url地址。
而system_url这个东西很奇怪,是获取系统的url路径。但实际上,由于system路径并没有直接执行的脚本,所以这个方法的实际用途是什么,暂时不知。有知道的童鞋麻烦告知。
具体的方法实现,这里不赘述了。直接贴出源码:
function site_url($uri = '') { /* 没有设置uri,使用base_url + index_page */ if ($uri == '') { return $this->slash_item('base_url').$this->item('index_page'); } /* enable_query_strings未启用,可以添加suffix后缀 */ if ($this->item('enable_query_strings') == FALSE) { $suffix = ($this->item('url_suffix') == FALSE) ? '' : $this->item('url_suffix'); return $this->slash_item('base_url').$this->slash_item('index_page').$this->_uri_string($uri).$suffix; } /* 否者不添加suffix后缀 */ else { return $this->slash_item('base_url').$this->item('index_page').'?'.$this->_uri_string($uri); } } /* 获取base_url,注意与site_url的区别 */ function base_url($uri = '') { return $this->slash_item('base_url').ltrim($this->_uri_string($uri), '/'); } /* 获取system url */ function system_url() { /* 获取系统目录. BASEPATH:/search/xx/phpCode/CI/system/ */ $x = explode("/", preg_replace("|/*(.+?)/*$|", "\\1", BASEPATH)); return $this->slash_item('base_url').end($x).'/'; }
5. 获取URI String: _uri_string
site_url和base_url都调用了_uri_string。这个函数是做什么用的呢?
按理来说, _uri_string的功能应该由URI组件来完成,这里却放在了Config组件中,似乎有些不妥(实际上,_uri_string是为base_url和site_url专属服务的)。
对于这样的uri:
<span>array( 'p1' </span>=> 'param1',<span> 'p2' </span>=<span>> 'param2' )</span>
如果enable_query_string为false,则_uri_string处理过后是这样的形式:
param1/param2
而enable_query_string为true,则处理后的形式是这样的:
p1=param1&p2=param2
这是我们常见(虽然很难看且SEO不好)的形式。改方法的实现源码:
protected function _uri_string($uri) { /* enable_query_strings 为false,直接implode */ if ($this->item('enable_query_strings') == FALSE) { if (is_array($uri)) { $uri = implode('/', $uri); } $uri = trim($uri, '/'); } /* 否者,拼接成类似param1=param1¶m2=param2的形式 */ else { if (is_array($uri)) { $i = 0; $str = ''; foreach ($uri as $key => $val) { /* 第一个参数前面不需要加& */ $prefix = ($i == 0) ? '' : '&'; $str .= $prefix.$key.'='.$val; $i++; } $uri = $str; } } return $uri; }
6. 设置配置项 set_item _assign_to_config
与item()相反,set_item用于设置配置项。如果配置项已经存在,则会被覆盖:
$this->config[$item] = $value;
_assign_to_config同set_item,该方法提供了数组的设置方式(调用set_item。我们之前在解释CodeIgniter.php文件的时候提到过:改方法允许在index.php中设置独立的配置项,且index.php中的配置具有更高的优先权(会覆盖主配置文件中的配置):
function _assign_to_config($items = array()) { if (is_array($items)) { foreach ($items as $key => $val) { $this->set_item($key, $val); } } }
到这里,Config组件的基本解析就算是完成了,我们再次回顾下该组件的基本功能:
最后感慨一下,一个好的Config组件,会省不少事啊。

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











Java 프레임워크에 대한 상용 지원의 비용/성능 평가에는 다음 단계가 포함됩니다. 필요한 보증 수준과 SLA(서비스 수준 계약) 보장을 결정합니다. 연구지원팀의 경험과 전문성. 업그레이드, 문제 해결, 성능 최적화와 같은 추가 서비스를 고려하십시오. 위험 완화 및 효율성 향상을 기준으로 비즈니스 지원 비용을 평가합니다.

PHP 프레임워크의 학습 곡선은 언어 숙련도, 프레임워크 복잡성, 문서 품질 및 커뮤니티 지원에 따라 달라집니다. PHP 프레임워크의 학습 곡선은 Python 프레임워크에 비해 높고 Ruby 프레임워크에 비해 낮습니다. Java 프레임워크에 비해 PHP 프레임워크는 학습 곡선이 적당하지만 시작하는 데 걸리는 시간이 더 짧습니다.

경량 PHP 프레임워크는 작은 크기와 낮은 리소스 소비를 통해 애플리케이션 성능을 향상시킵니다. 그 특징은 다음과 같습니다: 작은 크기, 빠른 시작, 낮은 메모리 사용량, 향상된 응답 속도 및 처리량, 리소스 소비 감소 실제 사례: SlimFramework는 500KB에 불과한 REST API를 생성하며 높은 응답성과 높은 처리량을 제공합니다.

Google Manager에서 사용자를 어떻게 추가하고 관리하나요? Chrome은 여러 사용자의 로그인을 지원하므로 여러 기기에 걸쳐 로그인하는 것에 대해 걱정할 필요가 없습니다. 일부 친구는 작동 방법을 모를 수도 있습니다. 걱정하지 마세요. 오늘 편집자가 모든 사람을 위한 자세한 단계별 튜토리얼을 준비했습니다. 관심이 있으시면 와서 편집자와 함께 살펴보세요. 자세한 단계별 튜토리얼 지침 1. 컴퓨터를 켠 후, 아래 그림과 같이 바탕 화면에 설치된 Google Chrome 아이콘을 찾아 두 번 클릭하여 엽니다. 2. 아래 그림과 같이 구글 크롬 오른쪽 상단에 있는 점 세 개 아이콘을 클릭하세요. 3. 아래 그림과 같이 Google Chrome의 드롭다운 메뉴에서 [설정] 옵션을 클릭하세요. 4. 열리는 Google Chrome 설정 인터페이스에서 [채널 관리]를 클릭합니다.

Golang 프레임워크에서는 명확하고 포괄적인 문서를 작성하는 것이 중요합니다. 모범 사례에는 Google의 Go 코딩 스타일 가이드와 같은 확립된 문서 스타일을 따르는 것이 포함됩니다. 제목, 부제, 목록 등 명확한 조직 구조를 사용하고 탐색 기능을 제공하세요. 시작 안내서, API 참조 및 개념을 포함하여 포괄적이고 정확한 정보를 제공합니다. 코드 예제를 사용하여 개념과 사용법을 설명합니다. 문서를 계속 업데이트하고, 변경 사항을 추적하고, 새로운 기능을 문서화하세요. GitHub 문제 및 포럼과 같은 지원 및 커뮤니티 리소스를 제공합니다. API 문서와 같은 실용적인 예제를 만듭니다.

애플리케이션 시나리오를 기반으로 최고의 Go 프레임워크를 선택하세요. 애플리케이션 유형, 언어 기능, 성능 요구 사항 및 생태계를 고려하세요. Common Go 프레임워크: Gin(웹 애플리케이션), Echo(웹 서비스), Fiber(높은 처리량), gorm(ORM), fasthttp(속도). 실제 사례: REST API(Fiber) 구축 및 데이터베이스(gorm)와 상호 작용. 프레임워크를 선택하세요. 주요 성능을 위해서는 fasthttp를 선택하고, 유연한 웹 애플리케이션을 위해서는 Gin/Echo를, 데이터베이스 상호작용을 위해서는 gorm을 선택하세요.

Go 프레임워크 개발에서 일반적인 과제와 해결 방법은 다음과 같습니다. 오류 처리: 관리에는 오류 패키지를 사용하고 중앙에서 오류를 처리하려면 미들웨어를 사용합니다. 인증 및 권한 부여: 타사 라이브러리를 통합하고 사용자 정의 미들웨어를 생성하여 자격 증명을 확인합니다. 동시 처리: 고루틴, 뮤텍스 및 채널을 사용하여 리소스 액세스를 제어합니다. 단위 테스트: 격리를 위해 getest 패키지, 모의 및 스텁을 사용하고, 충분성을 보장하기 위한 코드 적용 도구를 사용합니다. 배포 및 모니터링: Docker 컨테이너를 사용하여 배포를 패키징하고, 데이터 백업을 설정하고, 로깅 및 모니터링 도구를 사용하여 성능과 오류를 추적합니다.

Go 프레임워크 학습에는 다섯 가지 오해가 있습니다. 프레임워크에 대한 과도한 의존과 제한된 유연성입니다. 프레임워크 규칙을 따르지 않으면 코드를 유지 관리하기가 어려워집니다. 오래된 라이브러리를 사용하면 보안 및 호환성 문제가 발생할 수 있습니다. 패키지를 과도하게 사용하면 코드 구조가 난독화됩니다. 오류 처리를 무시하면 예기치 않은 동작과 충돌이 발생합니다.
