


CI フレームワークのソース コードの読み取りメモ 7 構成管理コンポーネント Config.php、ciconfig.php_PHP チュートリアル
CI フレームワークのソース コードの読み取りメモ 7 構成管理コンポーネント Config.php、ciconfig.php
柔軟で制御可能なアプリケーションでは、必然的に多数の制御可能なパラメーター (これらを構成と呼びます) が存在します。 CI の主な構成 構成ファイル (ここでは Application/Config/Config.php ファイルを指します) には、次のような複数の構成があります:
リーリーそれだけでなく、CI を使用すると、メイン設定ファイルの外に設定パラメータを配置することもできます。たとえば、独自の構成ファイルを Config_app.php として定義し、次のようにアプリケーション コントローラーに構成ファイルをロードできます。 リーリー
CI はこのようなさまざまな設定項目や設定ファイルをどのように管理しているのでしょうか?これが今日追跡する内容です: CI の構成管理コンポーネント - Config.php.まずこのコンポーネントのクラス図を見てください:
_config_paths: 検索する設定ファイルのパス。ここでは APPPATH ディレクトリを指します。設定ファイルも APPPATH の下にある必要があります。
Config: この配列は、すべての構成アイテムの保存に使用されます
Is_loaded: ロードされたすべての設定ファイルのリストを保存します。
_construct: コンポーネントのコンストラクター。主にbase_urlを構成します。
_assign_to_config:index.php の設定項目がメイン設定ファイルの設定をオーバーライドできるようにします
_uri_string、site_url、base_url、system_url: URI、プロジェクトパス、およびその他の関連処理。
load: 設定ファイルをロードします。
item: 構成アイテムを取得します
slash_item: item と同じですが、最後に "" 区切り文字が追加される点が異なります。通常、slash_item が必要になるのは site_url、base_url などだけです。
各メソッドの具体的な実装を分析してみましょう:1.コンポーネントの初期化_construct
Common.php グローバル関数を分析するときに、Config コンポーネントがインスタンス化される前に、すべてのグループ構成ファイルが get_config() 関数を通じて取得されることを前述しました。 Config コンポーネントがインスタンス化されるとき、その後のアクセスと処理を容易にするために、すべての設定を独自のプライベート変数 $config に保存する必要があります。
リーリー
なぜなら、私たちのアプリケーションはbase_urlの値を取得する必要があることが多く、この値は必須ではありません(設定のbase_urlは空に設定できます)が、base_urlの値を空にしたくないからです。したがって、CI は、Config コンポーネントを初期化するときに、base_url に対して特定の処理を実行します。これは主に、Config.php でbase_url が空に設定されている場合に発生します。(1) $_SERVER['HTTP_HOST'] が設定されている場合、base_url はプロトコル (http または https) + $_SERVER['HTTP_HOST'] + SCIRPT_PATH:
の形式に設定されます。 リーリー(2)。それ以外の場合は、http://localhost/:
に直接設定されます。 リーリー(3) 同時に、後続のアクセスを容易にするために、base_url 構成アイテムを構成配列にマップします (後で set_item メソッドを使用します。ここで知っておく必要があるのは、それが構成アイテムに追加され、古い値):
リーリーbase_url 設定項目は多くのコンポーネントに必要であることがわかります。したがって、CI がbase_url の正確性を保証するために一定のエネルギーを費やすことは理解できます。
2.設定ファイルの読み込み
これは、Config コンポーネントのコア メソッドの 1 つです:
リーリーすべてのパラメータはオプションのパラメータです。
ここで、各仮パラメータの意味を簡単に説明します:
$fileロードする必要がある設定ファイルにはサフィックス名を含めることも、含めないこともできます。このパラメータが指定されていない場合は、デフォルトで Config.php ファイルがロードされます。 $user_sections
: ロードされた設定ファイルに別のセクションを使用するかどうか、独自の設定ファイルを定義する場合、設定ファイル内の設定項目が Config.php ファイルと異なる可能性があることを想像してみてください。構成項目内で構成項目が競合しています。 $section を true に指定すると、構成項目が上書きされるのを防ぐことができます。$fail_graceful
: ロードする設定ファイルが存在しない場合の処理。 Graceful は「優雅」を意味します。このパラメータが true に設定されている場合、ファイルが存在しない場合はエラーを表示せずに false のみを返します。このメソッドの具体的な実装を見てみましょう:
(1). 設定ファイル名の前処理:
リーリー この $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衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











Java フレームワークの商用サポートのコスト/パフォーマンスを評価するには、次の手順が必要です。 必要な保証レベルとサービス レベル アグリーメント (SLA) 保証を決定します。研究サポートチームの経験と専門知識。アップグレード、トラブルシューティング、パフォーマンスの最適化などの追加サービスを検討してください。ビジネス サポートのコストと、リスクの軽減と効率の向上を比較検討します。

PHP フレームワークの学習曲線は、言語熟練度、フレームワークの複雑さ、ドキュメントの品質、コミュニティのサポートによって異なります。 PHP フレームワークの学習曲線は、Python フレームワークと比較すると高く、Ruby フレームワークと比較すると低くなります。 Java フレームワークと比較すると、PHP フレームワークの学習曲線は中程度ですが、開始までの時間は短くなります。

軽量の PHP フレームワークは、サイズが小さくリソース消費が少ないため、アプリケーションのパフォーマンスが向上します。その特徴には、小型、高速起動、低メモリ使用量、改善された応答速度とスループット、および削減されたリソース消費が含まれます。 実際のケース: SlimFramework は、わずか 500 KB、高い応答性と高スループットの REST API を作成します。

Google マネージャーでユーザーを追加および管理するにはどうすればよいですか? Google Chrome は複数のユーザーによるログインをサポートしているため、複数のデバイスでのログインについて心配する必要はありません。ユーザー数が多い場合は、管理を追加する必要があります。友達の中には操作方法がわからない人もいるかもしれません。心配しないでください。エディターが今日、すべての人向けに詳細なステップバイステップのチュートリアルを作成しました。興味がある場合は、エディターにアクセスして見てください。詳しいステップバイステップのチュートリアル手順 1. コンピューターの電源を入れた後、以下の図に示すように、デスクトップにインストールされている Google Chrome アイコンを見つけてダブルクリックして開きます。 2. 下の図に示すように、Google Chrome の右上隅にある 3 つの点のアイコンをクリックします。 3. 以下の図に示すように、Google Chrome のドロップダウン メニューで [設定] オプションをクリックします。 4. 開いた Google Chrome 設定インターフェースで、[チャンネルの管理] をクリックします。

アプリケーションのシナリオに基づいて最適な Go フレームワークを選択します。アプリケーションの種類、言語機能、パフォーマンス要件、エコシステムを考慮します。一般的な Go フレームワーク: Jin (Web アプリケーション)、Echo (Web サービス)、Fiber (高スループット)、gorm (ORM)、fasthttp (速度)。実際のケース: REST API (Fiber) の構築とデータベース (gorm) との対話。フレームワークを選択します。主要なパフォーマンスには fasthttp、柔軟な Web アプリケーションには Jin/Echo、データベース インタラクションには gorm を選択してください。

さまざまな分野の Java フレームワーク学習ロードマップ: Web 開発: SpringBoot と PlayFramework。永続層: Hibernate と JPA。サーバー側のリアクティブ プログラミング: ReactorCore と SpringWebFlux。リアルタイム コンピューティング: ApacheStorm および ApacheSpark。クラウド コンピューティング: AWS SDK for Java および Google Cloud Java。

Go フレームワークの学習には、フレームワークへの過度の依存と柔軟性の制限という 5 つの誤解があります。フレームワークの規則に従わない場合、コードの保守が困難になります。古いライブラリを使用すると、セキュリティと互換性の問題が発生する可能性があります。パッケージを過度に使用すると、コード構造が難読化されます。エラー処理を無視すると、予期しない動作やクラッシュが発生します。

Go フレームワーク開発における一般的な課題とその解決策は次のとおりです。 エラー処理: 管理にはエラー パッケージを使用し、エラーを一元的に処理するにはミドルウェアを使用します。認証と認可: サードパーティのライブラリを統合し、資格情報を確認するためのカスタム ミドルウェアを作成します。同時処理: ゴルーチン、ミューテックス、チャネルを使用してリソース アクセスを制御します。単体テスト: 分離のために getest パッケージ、モック、スタブを使用し、十分性を確保するためにコード カバレッジ ツールを使用します。デプロイメントとモニタリング: Docker コンテナを使用してデプロイメントをパッケージ化し、データのバックアップをセットアップし、ログ記録およびモニタリング ツールでパフォーマンスとエラーを追跡します。
