検索

ホームページ >バックエンド開発 >PHPチュートリアル >ThinkPHP-31

ThinkPHP-31

PHP中文网
PHP中文网オリジナル
2016-07-30 13:31:571118ブラウズ

基本:

1. 基本概念

LAMP

LAMP は、Linux、Apache、MySQL、および PHP に基づくオープン リソース ネットワーク開発プラットフォームです。この用語はヨーロッパに由来しており、ヨーロッパではこれらのプログラムが標準の開発環境として一般的に使用されていました。名前は各プログラムの頭文字に由来しています。各プログラムは、その所有権においてオープン ソース標準に準拠しています。Linux はオープン システムであり、Apache は、Web ベースの管理用の追加ツールを備えたリレーショナル データベースです。他の言語の優れた機能の多くを利用して、Web 開発をより効率的にします。 Windows オペレーティング システム上の Linux 環境でこれらのツールを使用する開発者は、WAMP を使用して呼び出されます。
これらのオープン ソース プログラム自体は、他のいくつかのプログラムと連携して動作するように特別に設計されているわけではありませんが、これらはすべて影響力のあるオープン ソース ソフトウェアであり、多くの共通の特性を共有しているため、これらのコンポーネントは一緒に使用されることがよくあります。過去数年間にわたって、これらのコンポーネントの互換性は向上し続けており、それらを組み合わせて使用​​することがより一般的になりました。そして、さまざまなコンポーネント間の連携を改善するために、特定の拡張機能を作成しました。現在、これらの製品は、ほとんどすべての Linux ディストリビューションにデフォルトで含まれています。 Linux オペレーティング システム、Apache サーバー、MySQL データベース、Perl、PHP、または Python 言語、これらの製品が連携して強力な Web アプリケーション プラットフォームを形成します。
オープンソーストレンドの活発な発展に伴い、オープンソースLAMPはJ2EEおよび.Net商用ソフトウェアと三位一体のトレンドを形成しており、ソフトウェア開発プロジェクトはソフトウェアへの投資コストが低いため、IT全体の注目を集めています。コミュニティ。 Web サイトのトラフィックに関しては、LAMP が最も強力な Web サイト ソリューションです。


OOP

オブジェクト指向プログラミング (OOP、オブジェクト指向プログラミング) は、コンピューター プログラミング アーキテクチャです。 OOP の基本原理は、コンピューター プログラムがサブルーチンとして機能する個々のユニットまたはオブジェクトで構成されるということです。 OOP は、再利用性、柔軟性、拡張性というソフトウェア エンジニアリングの 3 つの主な目標を達成します。全体的な操作を実現するために、各オブジェクトは情報を受信し、データを処理し、他のオブジェクトに情報を送信できます。 OOP には主に次の概念とコンポーネントがあります:
コンポーネント - 実行中のコンピューター プログラム内でデータと機能が一緒に形成される単位。コンポーネントは、OOP コンピューター プログラムのモジュールと構造の基礎です。
抽象性 - プログラムには、処理される情報の特定の側面を無視する機能、つまり、情報の主要な側面に焦点を当てる機能があります。
カプセル化 - 情報カプセル化とも呼ばれます。コンポーネントが他のコンポーネントの内部状態を予期しない方法で変更しないようにします。内部状態を変更するメソッドを提供するコンポーネントのみが内部状態にアクセスできます。各タイプのコンポーネントは、他のコンポーネントと通信するためのインターフェイスを提供し、他のコンポーネントが呼び出すメソッドを指定します。
ポリモーフィズム - コンポーネント参照とクラス アセンブリには、他の多くの異なるタイプのコンポーネントが含まれており、コンポーネントの参照によって生成される結果は、実際の呼び出しタイプに基づく必要があります。
継承 - 既存のコンポーネントに基づいてサブクラス化されたコンポーネントを作成できるようにし、ポリモーフィズムとカプセル化を統合および強化します。通常、クラスはコンポーネントをグループ化するために使用されますが、新しいクラスを既存のクラスの拡張として定義することもできるため、クラスをツリ​​ー構造またはネットワーク構造に編成して、アクションの多用途性を反映できます。
コンポーネントベースのプログラミングは、抽象化、カプセル化、再利用性、使いやすさなどの理由から、スクリプト言語で特に人気があります。


MVC

MVC は、アプリケーションの入力、処理、出力の分離を強制する設計パターンです。 MVC を使用するアプリケーションは、モデル (M)、ビュー (V)、およびコントローラー (C) の 3 つのコア コンポーネントに分割されており、それぞれが独自のタスクを処理します。
ビュー: ビューは、ユーザーが表示して操作するインターフェイスです。旧来の Web アプリケーションの場合、ビューは HTML 要素で構成されるインターフェイスです。新しいスタイルの Web アプリケーションでも、HTML はビュー内で重要な役割を果たしていますが、Adobe Flash や一部のマークアップ言語など、いくつかの新しいテクノロジが際限なく登場しています。 XHTML、XML/XSL、WML などの Web サービスアプリケーションのインターフェイスをどのように扱うかは、ますます困難になってきています。 MVC の大きな利点の 1 つは、アプリケーションのさまざまなビューを処理できることです。データがオンラインで保存されているか、従業員のリストで保存されているかに関係なく、ビューでは実際の処理は発生せず、データを出力してユーザーが操作できるようにする手段としてのみ機能します。
モデル: モデルは企業データとビジネス ルールを表します。 MVC の 3 つのコンポーネントの中で、モデルには最も多くの処理タスクがあります。たとえば、EJB や ColdFusion コンポーネントなどのコンポーネント オブジェクトを使用してデータベースを処理する場合があります。モデルによって返されるデータはニュートラルです。これは、モデルがデータ形式とは何の関係もないことを意味するため、モデルは複数のビューにデータを提供できます。モデルに適用されるコードは 1 回記述するだけで済み、複数のビューで再利用できるため、コードの重複が削減されます。
コントローラー: コントローラーはユーザー入力を受け入れ、モデルとビューを呼び出してユーザーのニーズを満たします。そのため、Web ページ内のハイパーリンクがクリックされて HTML フォームが送信された場合、コントローラー自体は何も出力したり、処理を実行したりしません。リクエストを受信し、リクエストを処理するためにどのモデル コンポーネントを呼び出すかを決定し、モデル処理によって返されたデータを表示するためにどのビューを使用するかを決定するだけです。
次に、MVC の処理プロセスを要約します。まず、コントローラーはユーザーのリクエストを受け取り、処理のためにどのモデルを呼び出すかを決定します。次に、モデルはビジネス ロジックを使用してユーザーのリクエストを処理し、データを返します。データは、対応するビューとともに返され、プレゼンテーション層を通じてユーザーに表示されます。


ORM

オブジェクト/リレーションマッピング (略してORM) は、オブジェクト指向ソフトウェア開発手法の発展とともに生まれました。オブジェクト指向開発手法は、今日のエンタープライズレベルのアプリケーション開発環境における主流の開発手法であり、リレーショナルデータベースは、エンタープライズレベルのアプリケーション環境でデータを永続的に保存する主流のデータストレージシステムです。オブジェクトとリレーショナル データは、ビジネス エンティティの 2 つの表現形式です。ビジネス エンティティは、メモリ内ではオブジェクトとして、データベース内ではリレーショナル データとして表されます。メモリ内のオブジェクト間には関連付けや継承関係がありますが、データベースではリレーショナル データは多対多の関連付けや継承関係を直接表現できません。したがって、オブジェクト リレーショナル マッピング (ORM) システムは一般にミドルウェアの形式で存在し、主にプログラム オブジェクトからリレーショナル データベース データへのマッピングを実装します。
オブジェクト指向はソフトウェア工学の基本原理 (結合、集約、カプセル化など) に基づいて開発されますが、リレーショナル データベースは数学理論に基づいて開発されます。この 2 つの理論には大きな違いがあります。この不一致現象を解決するために、オブジェクト リレーショナル マッピング技術が登場しました。


AOP

AOP(Aspect-Oriented Programming、アスペクト指向プログラミング)は、OOP(Object-Oriented Programming、オブジェクト指向プログラミング)を補完・改良したものと言えます。 OOP では、カプセル化、継承、ポリモーフィズムなどの概念を導入して、オブジェクト階層を確立し、一般的な動作のコレクションをシミュレートします。分散オブジェクトにパブリックな動作を導入する必要がある場合、OOP は無力です。つまり、OOP では上から下への関係を定義できますが、左から右への関係の定義には適していません。例えばロギング機能。ロギング コードは、すべてのオブジェクト階層にわたって水平に分散される傾向があり、分散先のオブジェクトのコア機能とは何の関係もありません。セキュリティ、例外処理、透過的な永続性など、他のタイプのコードにも同じことが当てはまります。この種の無関係なコードが随所に散在することは、OOP 設計では横断的コードと呼ばれ、大量のコードの重複につながり、さまざまなモジュールの再利用に役立ちません。 AOP 技術はその逆で、「クロスカッティング」と呼ばれる技術を使用してカプセル化されたオブジェクトの内部を解剖し、複数のクラスに影響を与えるパブリックな動作を再利用可能なモジュールにカプセル化します。その名前は「Aspect」です。側面。いわゆる「アスペクト」とは、簡単に言えば、システム内のコードの重複を減らし、結合を減らすために、ビジネスとは関係がないが、ビジネス モジュールによって一般的に呼び出されるロジックや責任をカプセル化することです。モジュール間を統合し、将来の操作性と保守性を向上させます。 AOP が水平的な関係を表すのは、「オブジェクト」がオブジェクトのプロパティと動作をカプセル化した中空の円筒である場合、アスペクト指向プログラミング手法は、これらの中空の円筒を切り開くようなものです。その内部の情報を入手します。カットされた断面はいわゆる「アスペクト」です。そして、これらの切断部分を驚異的な技術で跡形もなく復元しました。
「横断的」テクノロジーを使用して、AOP はソフトウェア システムを 2 つの部分 (中核的な懸念事項と横断的な懸念事項) に分割します。業務処理のメインプロセスが中心的な関心事であり、それとあまり関係のない部分が横断的な関心事です。横断的な懸念事項の特徴の 1 つは、それらが中核的な懸念事項の複数の場所で発生することが多いですが、基本的にはどこでも同様であるということです。権限認証、ロギング、トランザクション処理など。 Aop の役割は、システム内のさまざまな懸念事項を分離し、中核的な懸念事項と横断的な懸念事項を分離することです。アバナードのシニア ソリューション アーキテクトであるアダム マギー氏が述べたように、AOP の中心的な考え方は、「アプリケーション内のビジネス ロジックを、それをサポートする共通サービスから分離する」ことです。 ”


CURD

CURDはデータベーステクノロジーの略称で、一般的なプロジェクト開発におけるさまざまなパラメータの基本的な機能です。これは、作成、更新、読み取り、および削除の操作を表します。 CURD は、データを処理するための基本的なアトミック操作を定義します。 CURD が技術的に難しいレベルにまで引き上げられている理由は、複数のデータベース システムで CURD 操作を含む集計関連アクティビティを完了するパフォーマンスが、データ関係の変化に応じて大きく異なる可能性があるためです。
CURD は、特定のアプリケーションで作成、更新、読み取り、および削除メソッドを必ずしも使用するわけではありませんが、それらが実行する機能は同じです。たとえば、ThinkPHP は、add、save、select、および delete メソッドを使用して、モデルの CURD 操作を表します。


ActiveRecord

Active Record (中国語名: Active Record) は、リレーショナル データベース内のテーブルに対応するモデル クラスと、レコードの行に対応するモデル クラスのインスタンスによって特徴付けられるドメイン モデル パターンです。表にある。 Active Record と Row Gateway はよく似ていますが、前者はドメイン モデル、後者はデータ ソース モデルです。リレーショナル データベースは、多くの場合、外部キーを通じてエンティティの関係を表現します。また、Active Record は、この関係をデータ ソース レベルでのオブジェクトの関連付けと集計にマップします。 Active Record は、非常に単純なドメイン要件、特にドメイン モデルとデータベース モデルが非常に似ている場合に適しています。より複雑なドメイン モデル構造 (継承と戦略を使用したドメイン モデルなど) が発生した場合は、多くの場合、データ ソースを分離し、それをデータ マッパーと組み合わせるドメイン モデルを使用する必要があります。
Active Recordドライバーフレームワークは一般的にORMフレームワークの機能を備えていますが、Row Gatewayとの違いと同様に、Active Recordは単純なORMではありません。 Rails によって最初に提案されたこのモデルは、テーブルがレコードにマップされ、レコードがオブジェクトにマップされ、フィールドがオブジェクトのプロパティにマップされるという標準 ORM モデルに従っています。次の命名規則と構成規則を使用すると、モデルの操作を大幅に迅速に実現でき、簡潔で理解しやすくなります。


単一入口

単一エントリは、通常、プロジェクトまたはアプリケーションに統合された (ただし、必ずしも一意である必要はない) エントリ ファイルがあることを意味します。つまり、プロジェクトのすべての機能操作がこのエントリ ファイルを通じて実行され、多くの場合、エントリ ファイルが最初のステップで実行されます。
入り口が 1 つであることの利点は、同じ入り口にはさまざまな操作に対して同じルールが適用されることが多いため、プロジェクト全体が比較的標準化されていることです。また、入口が単一であることのメリットとして、傍受が便利なため制御が柔軟になり、一部の権限制御やユーザーログインなどの判断や操作を統一的に扱えることも挙げられます。
すべての Web サイトが 1 つのエントリ ファイルを通じてアクセスされるのではないかと心配する人もいるかもしれませんが、実際、これは根拠のない考えです。

2. ディレクトリ構造


ディレクトリ/ファイル 説明
ThinkPHP.php フレームワークエントリーファイル
共通 フレームワークパブリックファイルディレクトリ
会議 フレームワーク構成ファイルディレクトリ
Lang フレームワークシステム言語ディレクトリ
Lib システムコア基本クラスライブラリディレクトリ
Tpl システムテンプレートディレクトリ
Extend フレームワーク拡張ディレクトリ (約拡張ディレクトリの詳細については、後の拡張章を参照してください)

注: コア バージョンをダウンロードすると、ThinkPHP 自体は拡張機能に依存しないため、Extend ディレクトリが空になる可能性があります。



3. 命名規則

ThinkPHP で開発する場合は、次の命名規則に従うようにしてください:

  • クラス ファイルにはすべて .class.php という接尾辞が付けられます (これは内部使用を指します)。 ThinkPHP クラス ライブラリ ファイルの名前は、外部からロードされたクラス ライブラリ ファイルを表しません)、キャメルケースの名前を使用し、DbMysql.class.php のように最初の文字が大文字になっていることを確認してください。 Unix システムでは、クラスでは大文字と小文字が区別されるため、呼び出しの大文字と小文字は一致します (デバッグ モードの ThinkPHP は、Windows プラットフォームでも大文字と小文字の区別を厳密にチェックします)

  • クラス名とファイル名は一致しています (前述の一貫したケースを含む)。たとえば、UserAction クラスのファイル名は UserAction.class.php、InfoModel クラスのファイル名は InfoModel.class.php、さまざまなクラス ライブラリのクラス命名には特定の基準があります。 ;

  • 関数、設定ファイル、およびその他のクラス ライブラリ ファイル その他の関数には、通常 .php 接尾辞が付いています (サードパーティによって導入された関数には必須ではありません)。 ;

  • メソッドはキャメルケースを使用して名前が付けられ、getUserName、_parseType など、最初の文字は小文字またはアンダースコア "_" が使用されます。通常、アンダースコアで始まるメソッドはプライベート メソッドです。キャメルケースを使用し、最初の文字が小文字かアンダースコア「_」が使用されます ( tableName 、 _instance など)。通常、アンダースコアで始まる属性はプライベート属性です。

  • 二重アンダースコア「__」で始まる関数またはメソッド。 __call や __autoload などのマジック メソッドとして使用されます。

  • 定数名は、HAS_ONE や MANY_TO_MANY のように、大文字とアンダースコアで名前が付けられます。

  • 構成パラメータは、HTML_CACHE_ON のように、大文字とアンダースコアで名前が付けられます。

  • 言語変数は、MY_LANG のように大文字とアンダースコアで名前が付けられます。アンダースコアで始まる言語変数は、通常、_CLASS_NOT_EXIST_ などのシステム言語変数に使用されます。

  • 変数の名前付けに必須の指定はありません。

  • ThinkPHP のテンプレート ファイルのデフォルトは接尾辞として .html です (設定を通じて変更可能)

  • データ テーブルとフィールドの名前は小文字で下線が引かれていますので注意してください。 think_user テーブルや user_name フィールドなどのフィールド名をアンダースコアで始めないでください。_username などのデータ テーブル フィールドはフィルタリングされる可能性があります。

  • ThinkPHP では、関数の名前付けに特殊なケースがあり、これは 1 文字の大文字関数です。このような関数は通常、特定の操作のショートカット定義であるか、特別な関数を持ちます。例えばADSL方式など。

    もう 1 つの非常に重要な点は、ThinkPHP はデフォルトで UTF-8 エンコーディングを使用するため、プログラム ファイルが UTF-8 エンコーディング形式で保存されていることを確認し、BOM 情報ヘッダーを削除してください (BOM ヘッダー情報を削除するにはさまざまな方法があります。エディタなどの設定方法があり、一元的に検出・処理するツールを使用することもできます）、そうしないと予期せぬ問題が発生する可能性があります。

    • 4. CBD アーキテクチャ

ThinkPHP3.0 バージョンでは、新しい CBD (コア + ビヘイビア + ドライバー) アーキテクチャ モデルが導入されています。これは、フレームワークが最も重要なコア + ビヘイビア + ドライバー アーキテクチャ システムを採用しているためです。パーツは保持され、ラベルはマーキングのために重要な位置に設定されます。開発者は、独自のニーズに基づいて特定のラベルの位置を拡張したり、置き換えたりすることができます。また、アプリケーション層に独自のラベル位置とアプリケーション行を追加することもできます。ラベルの位置は、AOP 概念の「アスペクト」に似ており、システムの組み込みコア拡張機能が標準モードと見なされる場合、ユーザーはこのすべての動作のカスタマイズを使用できます。新しいパターンにパッケージ化されるため、ThinkPHP ではパターン拡張と呼ばれます。実際、パターン拡張は動作を置き換えたり追加したりするだけでなく、カスタマイズされたカスタマイズの目的を達成するために基礎となる MVC を置き換えたり変更したりすることもできます。この新機能を使用すると、開発者はパターン拡張機能を通じて自分自身または自社の開発フレームワークを簡単にカスタマイズできます。パターン拡張機能の新しいバージョンは、フレームワーク拡張機能のマスターであり、新しいマイルストーンを作成します。これがまさに新しいバージョンの本当の美しさです。 。

5. 開発プロセス

ThinkPHP を使用してアプリケーションを作成するための一般的な開発プロセスは次のとおりです:


システム設計、データベースとデータ テーブルの作成 (オプション)

プロジェクトに名前を付け、プロジェクト エントリ ファイルを作成します。デバッグ モードをオンにします。

プロジェクトの構成を完了します。

  • プロジェクト関数ライブラリを作成します。(オプション)

  • プロジェクトに必要な拡張機能 (モード、ドライバー、タグ ライブラリなど) を開発します。 ; (オプション)

  • コントローラー クラスを作成する; (オプション)

    • テンプレート ファイルを作成する

  • キャッシュ機能を開発および設定します。 (オプション)

  • ルーティング サポートを追加します。 (オプション)

  • 本番環境にデプロイします。

6. エントリーファイル


ThinkPHP は、プロジェクトのデプロイメントとアクセスに単一エントリーモードを採用しており、どの機能が完了しても、プロジェクトには統一された (ただし、唯一であるとは限りません) エントリーがあります。すべてのプロジェクトはエントリ ファイルから始まり、すべてのプロジェクトのエントリ ファイルは類似していると言うべきです。 エントリ ファイルには主に以下が含まれます:

フレームワーク パス、プロジェクト パス、およびプロジェクト名を定義します (オプション)

  • デバッグ モードと実行モードに関連する定数を定義します (オプション)

  • フレームワーク エントリ ファイルをロードします (必須)

7. プロジェクト ディレクトリ


生成されたプロジェクト ディレクトリ構造は、以下を含むシステム ディレクトリと似ています。 ：directory

description

CommonProjectパブリックファイルディレクトリは、通常、プロジェクトのパブリック機能を配置します。 index.php を App ディレクトリの外に移動する必要がある場合は、プロジェクト名とプロジェクト パスの定義をエントリ ファイルに追加するだけです。 7579d54425a1bbac5ca33fd2e0e31d55 'Index', / / デフォルトモジュール

  • 'URL_MODEL' => '2', // URL モード

  • 'SESSION_AUTO_START' => true, // セッションを開くかどうか

  • // その他の設定パラメータ

  • ); 詳細情報を設定するには、次のようにします。 

    • //项目配置文件
 return array(
    'DEFAULT_MODULE'     => 'Index', //默认模块
    'URL_MODEL'          => '2', //URL模式
    'SESSION_AUTO_START' => true, //是否开启session
    'USER_CONFIG'        => array(
        'USER_AUTH' => true,
        'USER_TYPE' => 2,
    ),
    //更多配置参数
    //...
 );

  • 二次パラメータ設定では大文字と小文字が区別されることに注意してください。つまり、読み取り値が定義と一致している必要があります。



    • 9. 従来の構成とプロジェクト構成、デバッグ構成

    構成よりも規則が重要であり、システムは組み込みの規則構成ファイル (Confconvention.php にあります) を持っています。共通パラメータは、ほとんどの用途に応じてデフォルトで設定されます。

      プロジェクト構成ファイルは最も一般的に使用される構成ファイルで、プロジェクトの構成ファイル ディレクトリ Conf の下にあり、ファイル名は config.php です。
    1. プロジェクト設定ファイルに組み込みパラメータ設定を追加するだけでなく、プロジェクトに必要な追加の設定パラメータを追加することもできます。
    アプリケーションの状態が設定されていない場合、システムはデフォルトでデバッグ状態になります。これは、デフォルトの設定パラメータが次のことを意味します: 

    'APP_STATUS' => 'debug', //应用调试模式状态


    debug.php 設定ファイルは、プロジェクト設定ファイルとシステムから異なるパラメータを設定するだけで済みます。構成ファイルまたは新しいパラメータをデバッグします。


    テストステータスなど、デバッグモードでアプリケーションのステータスを追加したい場合は、プロジェクト構成ファイルの設定を次のように変更できます: 

    'APP_STATUS' => 'test', //应用调试模式状态

    デバッグモードにはキャッシュがないため、 、より多くのファイル IO 操作が含まれ、テンプレートはリアルタイムでコンパイルされるため、デバッグ モードがオンになっている場合、パフォーマンスはある程度低下しますが、デプロイメント モードのパフォーマンスには影響しません。

    1. 注: デバッグ モードをオフにすると、プロジェクトのデバッグ構成ファイルはすぐに無効になります。


    10. グループ構成と読み取り構成、動的構成
    1. モジュールのグループ化が有効な場合、グループごとに構成ファイルを個別に定義でき、グループ構成ファイルは次の場所にあります。 /group Name/config.php

      次の設定を通じてグループ化を有効にできます:


      2. 'APP_GROUP_LIST' => 'Home,Admin', //项目分组设定
 'DEFAULT_GROUP'  => 'Home', //默认分组

    2. これで、Home と Admin の 2 つのグループが定義されたので、グループ化設定ファイルを次のように定義できます:

      3. Conf/Home/config.php
Conf/Admin/config.php
    各グループの設定ファイルは現在のグループ内でのみ有効であり、グループ設定の定義形式はプロジェクト設定と同じです。

    注: グループ名は大文字と小文字が区別され、定義されたグループ名と一致している必要があります。

    設定ファイルを定義した後、システムが提供する C メソッドを使用して (奇妙に感じる場合は、覚えやすくするために Config という単語を使用できます)、既存の設定を読み取ることができます:



    C ('パラメータ名') //設定されているパラメータ値を取得します

    1. 例えば、C('APP_STATUS')は、システムのデバッグモードの設定値を読み取ることができ、APP_STATUSがまだ設定されていない場合は、NULLが返されます。


    C メソッドは、2 次元構成を読み取るために使用することもできます:

    C('USER_CONFIG.USER_TYPE')//ユーザー構成内のユーザー タイプ設定を取得します

    1. 。構成パラメーターは次のとおりです。グローバルに有効なため、C メソッドは、特定の設定パラメーターの有効期限が切れた場合でも、どこからでも任意の構成を読み取ることができます。

    特定のアクション メソッドでは、特定のパラメーター (主にまだ使用されていないパラメーター) を動的に構成できます。
    新しい値を設定します:

    1. C('パラメータ名','新しいパラメータ値');

    たとえば、データキャッシュの有効期間を動的に変更する必要がある場合は、

      を使用できます。

    1. C(' DATA_CACHE_TIME','60');


    は、次のように操作にドット構文を使用して、2 次元配列の読み取りと設定をサポートすることもできます。 set：

    1. c（ 'user_config.user_type'）;バージョン 3.1 では、C 関数は設定保存機能をサポートしています。バッチ設定でのみ有効です。使用方法:

    C($array,'name');

    1. ここで、array は配列変数であり、名前で識別されるキャッシュ データへのバッチ設定後の構成パラメーターのリスト

    C('','name') // または C(null,'name'); を使用できます。名前で識別されたキャッシュ構成データを現在の構成データ (マージ) に読み取ります。


    1. 11. 拡張構成

      2. プロジェクト構成ファイルは、デプロイメント・モード中にコンパイル・キャッシュに組み込まれます。つまり、コンパイル後にプロジェクト構成ファイルを変更しても、すぐには反映されません。コンパイル キャッシュが有効になります。拡張設定ファイルはこの制限の影響を受けません。展開モードでも、変更された設定はリアルタイムで有効になり、設定形式はプロジェクト設定と同じになります。
    拡張設定の設定方法は以下の通りです(複数のファイルはカンマで区切ります):


      'LOAD_EXT_CONFIG' => 'user,db', // 拡張設定ファイルをロードします

      2. プロジェクトが設定されます拡張設定ファイルをロードするには、user .php と db.php がそれぞれユーザー設定とデータベース設定に使用され、プロジェクト設定ディレクトリの下にある設定ファイル Conf/user.php と Conf/db.php が自動的にロードされます。

    二次構成方法を使用する場合は、次のように設定できます:


    'LOAD_EXT_CONFIG' => array(


    'USER' => 'user', //ユーザー構成


    'DB ' => 'db', //データベース設定

    1. ), // 拡張設定ファイルをロードします

    同じ user.php 設定ファイルの内容ですが、ユーザーを取得する最後の方法パラメーターは次のようになります:

    1. C('USER.USER_AUTH_ID');

    2. このメソッドにより、大規模なプロジェクトの状況でのパラメーターの競合の問題を回避できます。

    3. 以下の一部の構成ファイルはシステムによって使用されています。カスタム拡張構成として再定義しないでください:

    4. ファイル名
    説明

    1. config.php

      プロジェクト構成ファイル

    tags.php


    プロジェクト動作設定ファイル

    Lang プロジェクト言語パックディレクトリ（オプション、多言語サポートが必要ない場合は削除可能）
    Lib プロジェクトクラスライブラリディレクトリ（通常はActionとModelサブディレクトリを含む）
    Tpl プロジェクトテンプレートdirectory 、テンプレート テーマをサポートします
    Runtime プロジェクト ランタイム ディレクトリ。これには、Cache (テンプレート キャッシュ)、Temp (データ キャッシュ)、Data (データ ディレクトリ)、および Logs (ログ ファイル) サブディレクトリが含まれます。グループがある場合は、最初にグループディレクトリ。
    alias.phpプロジェクトエイリアス定義ファイルdebug.phpプロジェクトデバッグモード設定ファイル(およびプロジェクトで設定されたAPP_STATUSに対応する設定ファイル) )core.php プロジェクトに追加されたコア コンパイル リスト ファイル (コア コンパイル リストは上書きされません)


    12. 関数ライブラリ


    ThinkPHP の関数ライブラリは、システム関数ライブラリとプロジェクト関数ライブラリに分けることができます。


    システム関数ライブラリ

    ライブラリ システム関数ライブラリは、システムの Common ディレクトリの下にあり、3 つのファイルがあります:
    common.php は、グローバルにロードする必要があり、どこからでも直接呼び出すことができる基本的な関数ライブラリです。 time;
    functions.php フレームワーク標準モードのパブリック関数ライブラリです。他のモードは、独自のパブリック関数ライブラリを置き換えてロードしたり、パブリック関数ライブラリ内の関数を再定義したりできます。はデバッグ モードまたはコンパイル プロセスでのみ使用されるため、そのメソッドをプロジェクト内で直接呼び出すことはできません。


    プロジェクト関数ライブラリは通常、グループ展開方式を使用し、「グループ名/関数.php」ファイルが存在する場合、このファイルは実行中に自動的にロードされ、プロジェクトのコンパイル統合キャッシュにマージされます。したがって、プロジェクト関数ライブラリのすべての関数は、手動でロードせずに直接使用することもできます。

    プロジェクト構成で動的関数ロード構成が使用されている場合、プロジェクト Common ディレクトリーの下にさらに多くの関数ファイルが存在する可能性があり、動的にロードされた関数ファイルはコンパイル キャッシュに含まれません。

    特殊なケースでは、このモードにより、自動的にロードされるプロジェクト ライブラリの場所または名前が変更されることがあります。



    拡張関数ライブラリ

    ライブラリ 必要に応じて読み込みと呼び出しを容易にするために、プロジェクトのパブリック ディレクトリの下に拡張関数ライブラリを定義できます。拡張機能ライブラリの関数定義仕様は、関数ライブラリのファイル名を任意に指定できる点を除き、プロジェクト関数ライブラリと同様です。 通常、拡張機能ライブラリはダイナミックローディングの設定をしないと自動的にロードされません。 。

    関数ロード

    システム関数ライブラリとプロジェクト関数ライブラリの関数は、ロードせずに直接呼び出すことができます。プロジェクトの拡張関数ライブラリでは、次の 2 つのメソッドを使用して呼び出すことができます。プロジェクト内で呼び出します 設定ファイルで LOAD_EXT_FILE パラメータを定義します。例:


    "LOAD_EXT_FILE"=>"user,db"

    1. 上記の設定により、プロジェクトのパブリック配下の拡張関数ライブラリ ファイルが作成されます。 user.php と db.php ディレクトリは実行中に自動的に読み込まれるため、プロジェクト内の拡張関数ライブラリ user.php と db.php の関数を直接呼び出すことができ、拡張関数ライブラリの関数の変更には時間がかかります。リアルタイムで効果を発揮します。

      手動ロード

      関数が個々のモジュールによって時々のみ使用される場合は、呼び出す必要があるときに自動ロードを使用する必要はありません。メソッドは次のとおりです。
      2. load("@.user" )



    @.user は、現在のプロジェクトのユーザー関数ファイルをロードすることを意味し、user.php 関数ライブラリ内の関数を直接拡張できます。

    1. 13クラスライブラリが含まれています。コントロールデバイスクラス
    モジュール名+アクション

    例: UserAction、InfoAction


    モデルクラス

    モデル名+モデル

    例: UserModel、InfoModel動作クラス動作名+動作のために例 CheckRouteBehaviorウィジェットクラスウィジェット名 + ウィジェット例えば、BlogInfoWidgetドライバクラスエンジン名+ドライバ名例えば、DbMysqlはmysqlデータベースドライバを意味し、ファイルとはファイルキャッシュドライバーのことです ディレクトリ 呼び出しパス 説明 Lib /corethink.corecoreライブラリパッケージ/behavior/think.behaviorbuilt-in behaviorライブラリパッケージ/driver
    Base クラス ライブラリ Base クラス ライブラリとは、ThinkPHP のコア基本クラス ライブラリと拡張基本クラス ライブラリを含む、ThinkPHP クラス ライブラリ仕様に準拠したシステム クラス ライブラリを指します。コア基本クラス ライブラリ ディレクトリはシステムの Lib ディレクトリにあり、拡張基本クラス ライブラリは Extend/Library ディレクトリにあり、ORG および Com 拡張クラス ライブラリを拡張できます。 。コア基本クラス ライブラリの役割は、フレームワークの汎用開発を完了するために必要な基本クラスと組み込みサポート クラスを完成させることです。次のものが含まれます。

    lib.driver

    built-in driverライブラリパッケージ

    Lib/TemplateThink.Template 内蔵テンプレートエンジンライブラリパッケージ

    コア クラス ライブラリ パッケージには、次のコア クラス ライブラリが含まれています:

    クラス名 説明
    アクション システム基本コントローラクラス
    App システムアプリケーションクラス
    行動 システム動作基本クラス
    Cache システムキャッシュクラス
    Db システム抽象データベースクラス
    Dispatcher URLディスパッチクラス
    Log システムログクラス
    Model システム基本モデルクラス
    Think システムエントリと静的クラス
    ThinkException システム基本例外クラス
    View Viewクラス
    システムウィジェットの基本class

    アプリケーション クラス ライブラリ

    アプリケーション クラス ライブラリは、プロジェクトで定義または使用されるクラス ライブラリも ThinkPHP の命名規則に従います。アプリケーション ライブラリ ディレクトリは、プロジェクト ディレクトリの下の Lib ディレクトリにあります。アプリケーション ライブラリには、アクション ライブラリ、モデル ライブラリ、またはその他のツール ライブラリを含む幅広い範囲があり、通常は

    Directory Calling path Description
    Lib/Action @ を含みます。 コントローラークラスライブラリパッケージ
    Lib/Model @.Model、または modelクラスライブラリパッケージ
    Lib/Behaviorを自動的にロードします Bメソッドを使用して呼び出すか、自動的にロードします ビヘイビアを適用しますクラスライブラリパッケージ
    Lib/Widget Wメソッドを使用してテンプレートを呼び出す Widgetクラスライブラリパッケージを適用

    项目根据自己的需要可以在项目类库目录下面添加自己的类库包，例如Lib/Common、Lib/Tool等。


    类库导入

    一、Import显式导入

    ThinkPHP模拟了Java的类库导入机制，统一采用import方法进行类文件的加载。import方法是ThinkPHP内建的类库导入方法，提供了方便和灵活的文件导入机制，完全可以替代PHP的require和include方法。例如：

    1. import("Think.Util.Session");
 import("App.Model.UserModel");

    import方法具有缓存和检测机制，相同的文件不会重复导入，如果导入了不同的位置下面的同名类库文件，系统也不会再次导入

    注意：在Unix或者Linux主机下面是区别大小写的，所以在使用import方法的时候要注意目录名和类库名称的大小写，否则会导入失败。对于import方法，系统会自动识别导入类库文件的位置，ThinkPHP的约定是Think、ORG、Com包的导入作为基类库导入，否则就认为是项目应用类库导入。

    1. import("Think.Util.Session");
 import("ORG.Util.Page");

    上面两个方法分别导入了Think基类库的Util/Session.class.php文件和ORG扩展类库包的Util/Page.class.php文件。

    要导入项目的应用类库文件也很简单，使用下面的方式就可以了，和导入基类库的方式看起来差不多：

    1. import("MyApp.Action.UserAction");
 import("MyApp.Model.InfoModel");

    上面的方式分别表示导入MyApp项目下面的Lib/Action/UserAction.class.php和Lib/Model/InfoModel.class.php类文件。


    通常我们都是在当前项目里面导入所需的类库文件，所以，我们可以使用下面的方式来简化代码

    1. import("@.Action.UserAction");
 import("@.Model.InfoModel");



    二，别名导入

    除了命名空间的导入方式外，import方法还可以支持别名导入，要使用别名导入，首先要定义别名，我们可以在项目配置目录下面增加alias.php 用以定义项目中需要用到的类库别名，例如：

    1. return array(
    'rbac' =>LIB_PATH.'Common/Rbac.class.php',
    'page' =>LIB_PATH.'Common/Page.class.php',
 );

    那么，现在就可以直接使用：

    1. import("rbac");
 import("page");

    导入Rbac和Page类，别名导入方式禁止使用import方法的第二和第三个参数，别名导入方式的效率比命名空间导入方式要高效，缺点是需要预先定义相关别名。



    导入第三方类库

    第三方类库统一放置在系统扩展目录下的Vendor 目录，并且使用vendor 方法导入，其参数和 import 方法是 一致的，只是默认的值有针对变化。 例如，我们把 Zend 的 Filter\Dir.php 放到 Vendor 目录下面，这个时候 Dir 文件的路径就是 Vendor\Zend\Filter\Dir.php，我们使用vendor 方法导入只需要使用：

    1. Vendor('Zend.Filter.Dir');

    就可以导入Dir类库了。
    Vendor方法也可以支持和import方法一样的基础路径和文件名后缀参数，例如：

    Vendor('Zend.Filter.Dir',dirname(__FILE__),'.class.php');

    自动加载

    在大多数情况下，我们无需手动导入类库，而是通过配置采用自动加载机制即可，自动加载机制是真正的按需加载，可以很大程度的提高性能。自动加载有三种情况，按照加载优先级从高到低分别是：别名自动加载、系统规则自动加载和自定义路径自动加载。

    一、别名自动加载

    在前面我们提到了别名的定义方式，并且采用了import方法进行别名导入，其实所有定义别名的类库都无需再手动加载，系统会按需自动加载。


    二、 系统规则自动加载

    果你没有定义别名的话，系统会首先按照内置的规则来判断加载，系统规则仅针对行为类、模型类和控制器类，搜索规则如下：

    类名 规则 说明
    行为类 规则1 搜索系统类库目录下面的Behavior目录
    规则2 搜索系统扩展目录下面的Behavior目录
    规则3 搜索应用类库目录下面的Behavior目录
    规则4 如果启用了模式扩展，则搜索模式扩展目录下面的Behavior目录
    模型类 规则1 如果启用分组，则搜索应用类库目录的Model/当前分组 目录
    规则2 搜索应用类库下面的Model目录
    规则3 搜索系统扩展目录下面的Model目录
    控制器类 规则1 如果启用分组，则搜索应用类库目录的Action/当前分组 目录
    规则2 搜索项目类库目录下面的Action目录
    规则3 搜索系统扩展目录下面的Action目录

    注意：搜索的优先顺序从上至下 ，一旦找到则返回，后面规则不再检测。如果全部规则检测完成后依然没有找到类库，则开始进行第三个自定义路径自动加载检测。



    三、 自定义路径自动加载

    当你的类库比较集中在某个目录下面，而且不想定义太多的别名导入的话，可以使用自定义路径自动加载方式，这种方式需要在项目配置文件中添加自动加载的搜索路径，例如：

    'APP_AUTOLOAD_PATH' =>'@.Common,@.Tool',

    1. 表示，在当前项目类库目录下面的Common和Tool目录下面的类库可以自动加载。多个搜索路径之间用逗号分割，并且注意定义的顺序也就是自动搜索的顺序。


    2. 注意：自动搜索路径定义只能采用命名空间方式，也就是说这种方式只能自动加载项目类库目录和基类库目录下面的类库文件。



    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


    控制器：

    1. URL模式

    传统方式的文件入口访问会变成由URL的参数来统一解析和调度。

    ThinkPHP支持四种URL模式，可以通过设置URL_MODEL参数来定义，包括普通模式、PATHINFO、REWRITE和兼容模式。


    一、普通模式：设置URL_MODEL 为0
    采用传统的URL参数模式

    1. http://serverName/appName/?m=module&a=action&id=1


    二、PATHINFO模式（默认模式）：设置URL_MODEL 为1
    默认情况使用PATHINFO模式，ThinkPHP内置强大的PATHINFO支持，提供灵活和友好URL支持。PATHINFO模式自动识别模块和操作，例如

    http://serverName/appName/module/action/id/1/或者
http://serverName/appName/module,action,id,1/





    三、REWRITE模式： 设置URL_MODEL 为2
    该URL模式和PATHINFO模式功能一样，除了可以不需要在URL里面写入口文件，和可以定义.htaccess 文件外。在开启了Apache的URL_REWRITE模块后，就可以启用REWRITE模式了，具体参考下面的URL重写部分。

    四、兼容模式： 设置URL_MODEL 为3
    兼容模式是普通模式和PATHINFO模式的结合，并且可以让应用在需要的时候直接切换到PATHINFO模式而不需要更改模板和程序，还可以和URL_WRITE模式整合。兼容模式URL可以支持任何的运行环境。

    兼容模式的效果是：

    1. http://serverName/appName/?s=/module/action/id/1/

    并且也可以支持参数分割符号的定义，例如在URL_PATHINFO_DEPR为~的情况下，下面的URL有效：

    1. http://serverName/appName/?s=module~action~id~1

    其实是利用了VAR_PATHINFO参数，用普通模式的实现模拟了PATHINFO的模式。但是兼容模式并不需要自己传s变量，而是由系统自动完成URL部分。正是由于这个特性，兼容模式可以和PATHINFO模式之间直接切换，而不需更改模板文件里面的URL地址连接。我们建议的方式是采用PATHINFO模式开发，如果部署的时候环境不支持PATHINFO则改成兼容URL模式部署即可，程序和模板都不需要做任何改动。


    2. 模块和操作

    http://域名/项目名/分组名/模块名/操作名/其他参数
    Dispatcher会根据URL地址来获取当前需要执行的项目、分组（如果有定义的话）模块、操作以及其他参数，在某些情况下，项目名可能不会出现在URL地址中（通常情况下入口文件则代表了某个项目，而且入口文件可以被隐藏）。
    每一个模块就是一个控制器类，通常位于项目的Lib\Action目录下面。

    3.1版本开始，增加ACTION_SUFFIX配置参数，用于设置操作方法的后缀。
    例如，如果设置：

    1. 'ACTION_SUFFIX'=>'Act'

    那么访问某个模块的add操作对应读取模块类的操作方法则由原来的add方法变成addAct方法。



    3. 定义控制器和空操作，空模块

    一个应用如果不需要和数据库交互的时候可以不需要定义模型类，但是必须定义Action控制器，一般位于项目的Lib/Action目录下面。
    Action控制器的定义非常简单，只要继承Action基础类就可以了，例如：

    1. Class UserAction extends Action{}

    控制器文件的名称是UserAction.class.php。

    空の操作とは、システムが指定された操作メソッドを見つけられない場合に、空の操作 (_empty) メソッドを見つけて実行することを意味します。このメカニズムを使用すると、エラー ページと一部の URL の最適化を実現できます。

    空のモジュールの概念は、システムが指定されたモジュール名を見つけられない場合、システムが空のモジュール (EmptyAction) を見つけようとすることを意味します。このメカニズムを使用して、エラー ページをカスタマイズし、URL を最適化できます。


    4. モジュールのグループ化

    モジュールのグループ化に関連する設定パラメータには以下が含まれます:

    設定パラメータ 説明
    APP_GROUP_LIST プロジェクトのグループ化リスト (設定とはグループ化を有効にすることを意味します)
    DEFAULT_GROUP デフォルトグループ(デフォルト値はホーム)
    TMPL_FILE_DEPR グループテンプレートの下のモジュールとオペレーションの区切り文字、デフォルト値は“/”です
    VAR_GROUP パラメータ名グループのデフォルトは g (通常モードの URL にのみ必要) です

    たとえば、現在のプロジェクトを、それぞれフロントエンド機能とバックエンド機能を表す Home と Admin の 2 つのグループに分割する場合、プロジェクト構成に次の構成を追加するだけで済みます:

    1. 'APP_GROUP_LIST ' => 'Home,Admin', //プロジェクト グループ設定

    2. 'DEFAULT_GROUP' => 'Home', //デフォルト グループ

    複数のグループはカンマで区切ることができます。悩ませる。



    5. URL 擬似静的

    ThinkPHP は、URL_HTML_SUFFIX パラメーターを設定することで、URL の通常の実行に影響を与えることなく、URL の末尾に必要な静的サフィックスを追加できます。現在の動作。たとえば、

    1. 'URL_HTML_SUFFIX'=>'shtml'

    を設定すると、次のURLを置くことができます

    1. http://serverName/Blog/read/id/1

    は

    1. http://serverName/Blog/read/id/1.shtml

    になります。後者は静的ページの URL 特性をより多く持ちますが、前の URL と同じ実行効果があり、影響はありません。オリジナルパラメータの使用。

    注: 擬似静的サフィックスを設定するときに、サフィックスに「.」を含める必要はありません。したがって、次の設定は実際には同等です:

    1. 'URL_HTML_SUFFIX'=>'.shtml'

    疑似静的設定後、一貫した URL を動的に生成する必要がある場合は、次の U メソッドを使用できます。テンプレート ファイルの URL を生成します。

    バージョン 3.1 以降、デフォルトですべての静的サフィックスがサポートされ、現在の疑似静的サフィックスは定数 __EXT__ に記録されますが、通常のページ アクセスには影響しません。現在の擬似静的サフィックスを取得したい場合は、定数 __EXT__ を介して取得するだけです。

    設定された疑似静的サフィックスをサポートしたいだけの場合は、複数のサフィックスをサポートするように直接設定できます。たとえば:

    1. 'URL_HTML_SUFFIX'=>'html|shmtl|xml' // 複数の分割|


    複数の擬似静的サフィックスが設定されている場合、U 関数を使用して生成された URL アドレスで最初のサフィックスが使用されます。また、URL アドレスを生成するためのサフィックスの指定もサポートされています。



    6. URL ルーティング

    ThinkPHP は URL ルーティング機能をサポートしており、URL_ROUTER_ON パラメーターを true に設定する必要があります。ルーティング機能を有効にし、URL_ROUTE_RULES パラメーターを構成すると、現在の URL に一致するルート名がルート定義内で見つかった場合、システムはルートの解析とリダイレクトを実行します。


    詳細については、http://doc.thinkphp.cn/manual/url_route.htmlを参照してください。


    7. URL書き換え

    詳細については、http://doc.thinkphp.cnを参照してください。 /manual/url_rewrite.html

    <code><code><code><code><code><code><code><code><code>

    <code><code><code><code><code><code><code><code><code>

    8. URL生成

    <code><code><code><code><code><code><code><code><code>为了配合所使用的URL模式，我们需要能够动态的根据当前的URL设置生成对应的URL地址，为此，ThinkPHP内置提供了U方法，用于URL的动态生成，可以确保项目在移植过程中不受环境的影响。
    U方法的定义规则如下（方括号内参数根据实际应用决定）：

    1. U('[分组/模块/操作]?参数' [,'参数','伪静态后缀','是否跳转','显示域名'])

    <code><code><code><code><code><code><code><code><code>如果不定义项目和模块的话 就表示当前项目和模块名称，下面是一些简单的例子：

    1. U('User/add') // 生成User模块的add操作的URL地址

    2. U('Blog/read?id=1') // 生成Blog模块的read操作 并且id为1的URL地址

    3. U('Admin/User/select') // 生成Admin分组的User模块的select操作的URL地址

    <code><code><code><code><code><code><code><code><code>U方法的第二个参数支持数组和字符串两种定义方式，如果只是字符串方式的参数可以在第一个参数中定义，例如：8. URL 生成

      <code><code><code><code><code><code><code><code><code>使用される URL モードと一致させるには、現在の URL 設定に基づいて対応する URL アドレスを動的に生成できる必要があります。この目的のために、ThinkPHP は、URL の動的生成に使用される組み込み U メソッドを提供します。これにより、移植プロセス中にプロジェクトが環境の影響を受けないようにすることができます。
    1. U メソッドの定義規則は次のとおりです (角括弧内のパラメータは実際のアプリケーションに応じて決定されます):

  • U('[グループ/モジュール/オペレーション]?パラメータ' [,'パラメータ' ,'疑似静的サフィックス','ジャンプするかどうか' ,'表示ドメイン名'])

  • <code><code><code><code><code><code><code><code><code> 定義されていない場合、プロジェクトとモジュールの場合は、現在のプロジェクトとモジュールの名前を表します。 は、いくつかの簡単な例です。

    🎜🎜U('User/add') //ユーザーモジュールの追加操作のURLアドレスを生成します🎜🎜🎜🎜U('Blog/read ?id=1') // ブログモジュールの読み取り操作のURLアドレスを生成し、IDは1です🎜🎜🎜 🎜U('Admin/User/select') // Admin グループの User モジュールの select 操作の URL アドレスを生成します🎜 🎜🎜🎜<code><code><code><code><code><code><code><code><code>U メソッドの 2 番目のパラメータは配列と文字をサポートします。文字列モードのパラメータのみを定義できる場合、文字列を定義するには 2 つの方法があります。最初のパラメータ、例: code> 🎜🎜🎜🎜U('ブログ/カテゴリー',array('cate_id'=>1,'ステータス'=> 1))🎜🎜🎜🎜U('ブログ/カテゴリー','cate_id= 1&status=1')🎜🎜🎜🎜U('ブログ/cate?cate_id=1&status=1')🎜

    • <code><code><code><code><code><code><code><code><code>三种方式是等效的，都是 生成Blog模块的cate操作 并且cate_id为1 status为1的URL地址
    但是不允许使用下面的定义方式来传参数

    1. U('Blog/cate/cate_id/1/status/1')

    <code><code><code><code><code><code><code><code><code>

    根据项目的不同URL设置，同样的U方法调用可以智能地对应产生不同的URL地址效果，例如针对

    1. U（'Blog/read?id=1'）这个定义为例。

    如果当前URL设置为普通模式的话，最后生成的URL地址是： 
    http://serverName/index.php?m=Blog&a=read&id=1
    如果当前URL设置为PATHINFO模式的话，同样的方法最后生成的URL地址是： 
    http://serverName/index.php/Blog/read/id/1
    如果当前URL设置为REWRITE模式的话，同样的方法最后生成的URL地址是： 
    http://serverName/Blog/read/id/1
    如果当前URL设置为REWRITE模式，并且设置了伪静态后缀为.html的话，同样的方法最后生成的URL地址是： 
    http://serverName/Blog/read/id/1.html
    U方法还可以支持路由，如果我们定义了一个路由规则为：

    1.  'news/:id\d'=>'News/read'

    那么可以使用

    1. U（'/news/1'）

    最终生成的URL地址是：

    1. http://serverName/index.php/news/1


    注意：如果你是在模板文件中直接使用U方法的话，需要采用 {:U('参数1', '参数2'…)} 的方式，具体参考模板引擎章节的8.3 使用函数内容。

    如果你的应用涉及到多个子域名的操作地址，那么也可以在U方法里面指定需要生成地址的域名，例如：

    1. U('Blog/read@blog.thinkphp.cn','id=1');

    @后面传入需要指定的域名即可。
    此外，U方法的第5个参数如果设置为true，表示自动识别当前的域名，并且会自动根据子域名部署设置APP_SUB_DOMAIN_DEPLOY和APP_SUB_DOMAIN_RULES自动匹配生成当前地址的子域名。
    如果开启了URL_CASE_INSENSITIVE，则会统一生成小写的URL地址。

    9. URL大小写

    只要在项目配置中，增加：

    1. 'URL_CASE_INSENSITIVE' =>true

    就可以实现URL访问不再区分大小写了。

    这里需要注意一个地方，如果我们定义了一个UserTypeAction的模块类，那么URL的访问应该是：

    1. http://serverName/index.php/user_type/list

    2.  //而不是

    3. http://serverName/index.php/usertype/list

    利用系统提供的U方法可以为你自动生成相关的URL地址。
    如果设置

    1. 'URL_CASE_INSENSITIVE' =>false

    的话，URL就又变成：

    1. http://serverName/index.php/UserType/list

    注意：URL不区分大小写并不会改变系统的命名规范，并且只有按照系统的命名规范后才能正确的实现URL不区分大小写。

    10. 前置和后置操作

    系统会检测当前操作是否具有前置和后置操作，如果存在就会按照顺序执行，前置和后置操作的方法名是在要执行的方法前面加 _before_和_after_，例如：

    1. class CityAction extends Action{
    //前置操作方法
    public function _before_index(){
        echo &#39;before&#39;;
    }
    public function index(){
        echo &#39;index&#39;;
    }
    //后置操作方法
    public function _after_index(){
        echo &#39;after&#39;;
    }
 }

    对于任何操作方法我们都可以按照这样的规则来定义前置和后置方法。

    <code><code><code><code><code><code><code><code><code>

    如果当前的操作并没有定义操作方法，而是直接渲染模板文件，那么如果定义了前置 和后置方法的话，依然会生效。真正有模板输出的可能仅仅是当前的操作，前置和后置操作一般情况是没有任何输出的。
    需要注意的是，在有些方法里面使用了exit或者错误输出之类的话 有可能不会再执行后置方法了。
    例如，如果在当前操作里面调用了系统Action的error方法，那么将不会再执行后置操作，但是不影响success方法的后置方法执行。

    <code><code><code><code><code><code><code><code><code>


    11. 跨模块调用

    <code>例如，我们在Index模块调用User模块的操作方法

    1. class IndexAction extends Action{
    public function index(){
        //实例化UserAction
        $User = new UserAction();
        //其他用户操作
         //...
        $this->display(); //输出页面模板
    }
 }

    因为系统会自动加载Action控制器，因此 我们不需要导入UserAction类就可以直接实例化。
    并且为了方便跨模块调用，系统内置了A方法和R方法。    $User = A('User');

    <code>事实上，A方法还支持跨分组或者跨项目调用，默认情况下是调用当前项目下面的模块。<br>跨项目调用的格式是：<br>A('[项目名://][分组名/]模块名')<br>例如：

    1. A(&#39;User&#39;) //表示调用当前项目的User模块
A(&#39;Admin://User&#39;) //表示调用Admin项目的User模块
A(&#39;Admin/User&#39;) //表示调用Admin分组的User模块
A(&#39;Admin://Tool/User&#39;) //表示调用Admin项目Tool分组的User模块


    R方法表示调用一个模块的某个操作方法，调用格式是：
    R('[项目名://][分组名/]模块名/操作名',array('参数1','参数2'…))
    例如：

    1. R(&#39;User/info&#39;) //表示调用当前项目的User模块的info操作方法
R(&#39;Admin/User/info&#39;) //表示调用Admin分组的User模块的info操作方法
R(&#39;Admin://Tool/User/info&#39;) //表示调用Admin项目Tool分组的User模块的info操作方法

    R方法还支持对调用的操作方法需要传入参数，例如User模块中我们定义了一个info方法：

    1. class UserAction extends Action{
    protected function info($id){
        $User = M(&#39;User&#39;);
        $User->find($id);
        //...
    }
 }

    接下来，我们可以在其他模块中调用：

    1. R('User/info',array(15))

    表示调用当前项目的User模块的info操作方法，并且id参数传入15



    12. 页面跳转

    <code><code>系统的Action类内置了两个跳转方法success和error，用于页面跳转提示，而且可以支持ajax提交。使用方法很简单，举例如下：

    1. $User = M(&#39;User&#39;); //实例化User对象
$result = $User->add($data); 
if($result){
    //设置成功后跳转页面的地址，默认的返回页面是$_SERVER[&#39;HTTP_REFERER&#39;]
    $this->success(&#39;新增成功&#39;, &#39;User/list&#39;);
} else {
    //错误页面的默认跳转页面是返回前一页，通常不需要设置
    $this->error(&#39;新增失败&#39;);
}

    Success和error方法都有对应的模板，并且是可以设置的，默认的设置是两个方法对应的模板都是：

    1. //默认错误跳转对应的模板文件
&#39;TMPL_ACTION_ERROR&#39; => THINK_PATH . &#39;Tpl/dispatch_jump.tpl&#39;;
//默认成功跳转对应的模板文件
&#39;TMPL_ACTION_SUCCESS&#39; => THINK_PATH . &#39;Tpl/dispatch_jump.tpl&#39;;

    也可以使用项目内部的模板文件

    1. //默认错误跳转对应的模板文件
&#39;TMPL_ACTION_ERROR&#39; => &#39;Public:error&#39;;
//默认成功跳转对应的模板文件
&#39;TMPL_ACTION_SUCCESS&#39; => &#39;Public:success&#39;;

    模板文件可以使用模板标签，并且可以使用下面的模板变量：

    $msgTitle 操作标题
    $message 页面提示信息
    $status 操作状态 1表示成功 0 表示失败 具体还可以由项目本身定义规则
    $waitSecond 跳转等待时间 单位为秒
    $jumpUrl 跳转页面地址

    success和error方法会自动判断当前请求是否属于Ajax请求，如果属于Ajax请求则会调用ajaxReturn方法返回信息，具体可以参考后面的AJAX返回部分。


    3.1版本开始，error和success方法支持传值，无论是跳转模板方式还是ajax方式 都可以使用assign方式传参。例如：

    1. $this->assign(&#39;var1&#39;,&#39;value1&#39;);
$this->assign(&#39;var2&#39;,&#39;value2&#39;);
$this->error(&#39;错误的参数&#39;,&#39;要跳转的URL地址&#39;);

    当正常方式提交的时候，var1和var2变量会赋值到错误模板的模板变量。
    当采用AJAX方式提交的时候，会自动调用ajaxReturn方法传值过去（包括跳转的URL地址url和状态值status）



    13. 重定向

    Action类的redirect方法可以实现页面的重定向功能。
    redirect方法的参数用法和U函数的用法一致（参考上面的URL生成部分），例如：

    1. //重定向到New模块的Category操作
$this->redirect(&#39;New/category&#39;, array(&#39;cate_id&#39; => 2), 5, &#39;页面跳转中...&#39;);

    上面的用法是停留5秒后跳转到News模块的category操作，并且显示页面跳转中字样，重定向后会改变当前的URL地址。
    如果你仅仅是想重定向要一个指定的URL地址，而不是到某个模块的操作方法，可以直接使用redirect方法重定向，例如：

    1. //重定向到指定的URL地址

    2. redirect('/New/category/cate_id/2', 5, '页面跳转中...')

    Redirect方法的第一个参数是一个URL地址。


    14. 获取系统变量

    1. $this->方法名("变量名",["过滤方法"],["默认值"])

    <code><code><code>方法名可以支持：

    方法名 含义
    _get 获取GET参数
    _post 获取POST参数
    _param 自动判断请求类型获取GET、POST或者PUT参数（3.1新增）
    _request 获取REQUEST 参数
    _put 获取PUT 参数
    _session 获取 $_SESSION 参数


    以上就是ThinkPHP- 31的内容，更多相关内容请关注PHP中文网（www.php.cn）！


    声明：
    この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
    前の記事：Nginx の Web キャッシュ サービスと Sina のオープンソース NCACHE モジュール (1)次の記事：Nginx の Web キャッシュ サービスと Sina のオープンソース NCACHE モジュール (1)

    関連記事

    続きを見る