ホームページ > 記事 > バックエンド開発 > ThinkPHP-3.1、thinkphp-3.1_PHP チュートリアル

ThinkPHP-3.1、thinkphp-3.1_PHP チュートリアル

WBOYオリジナル: 2016-07-13 09:44:231300ブラウズ

ThinkPHP-3.1、thinkphp-3.1

基本:

1. 基本概念

ランプ

LAMP は、Linux、Apache、MySQL、PHP をベースにしたオープンソースの Web 開発プラットフォームです。この用語はヨーロッパに由来しており、ヨーロッパではこれらのプログラムが標準の開発環境として一般的に使用されていました。名前は各プログラムの頭文字に由来しています。各プログラムは、その所有権においてオープンソース標準に準拠しています。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 は、再利用性、柔軟性、拡張性というソフトウェアエンジニアリングの 3 つの主な目標を達成します。全体的な操作を実現するために、各オブジェクトは情報を受信し、データを処理し、他のオブジェクトに情報を送信できます。 OOP には主に次の概念とコンポーネントがあります:
コンポーネント - 実行中のコンピュータープログラム内でデータと機能が一緒に形成される単位。コンポーネントは、OOP コンピュータープログラムのモジュールと構造の基礎です。
抽象性 - プログラムには、処理される情報の特定の側面を無視する機能、つまり、情報の主要な側面に焦点を当てる機能があります。
カプセル化 - 情報カプセル化とも呼ばれます。コンポーネントが他のコンポーネントの内部状態を予期しない方法で変更しないことを保証します。内部状態変更メソッドを提供するコンポーネントのみが内部状態にアクセスできます。各タイプのコンポーネントは、他のコンポーネントと通信するためのインターフェイスを提供し、他のコンポーネントが呼び出すメソッドを指定します。
ポリモーフィズム - コンポーネント参照とクラスセットには、他の多くの異なるタイプのコンポーネントが含まれており、参照されたコンポーネントによって生成される結果は、実際の呼び出しタイプによって異なります。
継承 - 既存のコンポーネントに基づいてサブクラス化されたコンポーネントを作成できるようにし、ポリモーフィズムとカプセル化を統合および強化します。通常、クラスはコンポーネントをグループ化するために使用されますが、新しいクラスを既存のクラスの拡張として定義することもできるため、クラスをツリー構造またはネットワーク構造に編成して、アクションの多用途性を反映できます。
コンポーネントベースのプログラミングは、抽象化、カプセル化、再利用性、使いやすさなどの理由から、スクリプト言語で特に人気があります。

MVC

MVC は、アプリケーションの入力、処理、出力の分離を強制する設計パターンです。 MVC を使用するアプリケーションは、モデル (M)、ビュー (V)、およびコントローラー (C) の 3 つのコアコンポーネントに分割されており、それぞれが独自のタスクを処理します。
View: View は、ユーザーが表示して操作するインターフェイスです。旧式の 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 テクノロジーはその逆で、「クロスカッティング」と呼ばれるテクノロジーを使用して、カプセル化されたオブジェクトの内部を解剖し、複数のクラスに影響を与えるパブリックな動作を再利用可能なモジュールにカプセル化し、それを「アスペクト」と呼びます。側面。いわゆる「アスペクト」とは、簡単に言えば、システム内のコードの重複を減らし、結合を減らすために、ビジネスとは関係がないが、ビジネスモジュールによって共同で呼び出されるロジックや責任をカプセル化することです。モジュール間の信頼性を高め、将来の信頼性を高めます。 AOP は水平関係を表します。「オブジェクト」がオブジェクトのプロパティと動作をカプセル化する中空の円筒である場合、アスペクト指向のプログラミング手法は、これらの中空の円筒を細かく切り分けるようなものです。中の情報。カットされた断面はいわゆる「アスペクト」です。そして、これらの切断部分を驚異的な技術で跡形もなく復元しました。
「横断的」テクノロジーを使用して、AOP はソフトウェアシステムを 2 つの部分、つまり中核的な関心事と横断的な関心事に分割します。業務処理のメインプロセスが中心的な関心事であり、それとあまり関係のない部分が横断的な関心事です。横断的な懸念事項の特徴の 1 つは、それらが中核的な懸念事項の複数の場所で発生することが多いですが、基本的にはどこでも同様であるということです。権限認証、ロギング、トランザクション処理など。 Aop の役割は、システム内のさまざまな懸念事項を分離し、中核的な懸念事項と横断的な懸念事項を分離することです。アバナードのシニアソリューションアーキテクトであるアダムマギー氏が述べたように、AOP の中心的な考え方は、「アプリケーション内のビジネスロジックを、それをサポートする共通サービスから分離する」ことです。

カード

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

アクティブレコード

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

単一入口

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

2. ディレクトリ構造

ディレクトリ/ファイル	説明
ThinkPHP.php	フレームワークエントリーファイル
共通	フレームワークの公開ファイルディレクトリ
会議	フレームワーク設定ファイルのディレクトリ
ラング	フレームワークシステム言語ディレクトリ
リブ	システムコア基本クラスライブラリディレクトリ
Tpl	システムテンプレートディレクトリ
延長	フレームワーク拡張ディレクトリ (拡張ディレクトリの詳細については、後述の拡張機能の章を参照してください)

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

3. 命名規則

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

クラスファイルにはすべて .class.php という接尾辞が付けられます (これは、ThinkPHP によって内部的に使用されるクラスライブラリファイルを指し、外部からロードされるクラスライブラリファイルを表すものではありません)。名前はキャメルケースを使用して付けられ、最初の文字は大文字になります。 DbMysql.class.php;
Unix 系システムでは大文字と小文字が区別されるため、ファイル名と呼び出しでは大文字と小文字が区別されるようにしてください (ThinkPHP はデバッグモードの Windows プラットフォームでも大文字と小文字を厳密にチェックします)。
get_client_ip; などの関数に名前を付けるときは、小文字とアンダースコアを使用します
メソッドはキャメルケースを使用して名前が付けられ、getUserName、_parseType など、最初の文字は小文字またはアンダースコア「_」が使用されます。通常、アンダースコアで始まるメソッドはプライベートメソッドです。
二重アンダースコア「__」で始まる関数またはメソッドは、__call や __autoload などのマジックメソッドとして使用されます。
定数名は、HAS_ONE や MANY_TO_MANY のように、大文字とアンダースコアで名前が付けられます。
言語変数は、MY_LANG のように、大文字とアンダースコアで名前が付けられます。アンダースコアで始まる言語変数は、通常、_CLASS_NOT_EXIST_;
変数の名前付けに必須の仕様はなく、チームの仕様に従って行うことができます;
ThinkPHP のテンプレートファイルは、デフォルトで接尾辞として .html になります (設定を通じて変更可能)。
ThinkPHP では、関数の名前付けには特殊なケースがあり、これは 1 文字の大文字関数です。このような関数は通常、特定の操作のショートカット定義であるか、特別な関数を持っています。例えばADSL方式など。
もう 1 つの非常に重要な点は、ThinkPHP はデフォルトで UTF-8 エンコーディングを使用するため、プログラムファイルが UTF-8 エンコーディング形式で保存されていることを確認し、BOM 情報ヘッダーを削除してください (BOM ヘッダー情報を削除するにはさまざまな方法がありますが、それぞれに異なります)エディタなどの設定方法があり、一元的に検出・処理するツールを使用することもできます）、そうしないと予期せぬ問題が発生する可能性があります。

4. CBD アーキテクチャ

5.開発プロセス

システム設計、データベースとデータテーブルの作成（オプション）
プロジェクトに名前を付けてプロジェクトエントリファイルを作成し、デバッグモードをオンにします。

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

生成されたプロジェクトディレクトリ構造は、システムディレクトリに似ており、次のものが含まれます。

//プロジェクト名を定義します
define('APP_NAME', 'App');
//プロジェクトパスを定義します
define('APP_PATH', './App/');
//フレームをファイルにロードします
'./App/ThinkPHP/ThinkPHP.php' が必要です;

APP_NAME

APP_PATH

8. デプロイメントディレクトリ

ディレクトリ/ファイル	説明
PHP について考える	システムディレクトリ（以下のディレクトリ構造は上記のシステムディレクトリと同じです）
公開	ウェブサイトのパブリックリソースディレクトリ (ウェブサイトの Css、Js、写真、その他のリソースを保存)
アップロード	Webサイトアップロードディレクトリ（ユーザーがアップロードする統合ディレクトリ）
ホーム	プロジェクトディレクトリ(以下のディレクトリ構成は上記のアプリケーションディレクトリと同じです)
管理者	バックエンド管理プロジェクトディレクトリ
…その他のプロジェクトディレクトリ
index.php	プロジェクトホームのエントリーファイル
管理者.php	プロジェクト管理者のエントリファイル
...その他のプロジェクトエントリファイル

実際、システムディレクトリとプロジェクトディレクトリは非 WEB アクセスディレクトリの下に配置でき、Web サイトディレクトリの下にはパブリックディレクトリとエントリファイルのみを配置する必要があるため、Web サイトのセキュリティが向上します。

define('RUNTIME_PATH','./App/temp/');

define('RUNTIME_FILE','./App/temp/runtime_cache.php');

構成ファイルで 2 次元配列を使用して、さらに多くの情報を構成することもできます。例:

'USER_AUTH' =>
9. 従来の構成、プロジェクト構成、デバッグ構成

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

デバッグモードにはキャッシュがないため、より多くのファイル IO 操作とテンプレートのリアルタイムコンパイルが必要となるため、デバッグモードをオンにするとパフォーマンスがある程度低下しますが、パフォーマンスには影響しません。展開モードの。

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

次の構成を通じてグループ化を有効にできます。

Home と Admin の 2 つのグループが定義されたので、次のようにグループ構成ファイルを定義できます:
Conf/Admin/config.php

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

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

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

C('DATA_CACHE_TIME','60');

C('USER_CONFIG.USER_TYPE');

C('USER_CONFIG.USER_TYPE','1');

C($array,'name');

C('','name') //または C(null,'name');

11. 拡張構成

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

'LOAD_EXT_CONFIG' =>

12.関数ライブラリ

システム関数ライブラリ

プロジェクト関数ライブラリ

拡張関数ライブラリ

機能ロード

"LOAD_EXT_FILE"=>"ユーザー,データベース"

ThinkPHP のクラスライブラリには、基本クラスライブラリとアプリケーションクラスライブラリが含まれています。システムのクラスライブラリの命名規則は次のとおりです。

基本クラスライブラリとは、ThinkPHP のコア基本クラスライブラリと拡張基本クラスライブラリを含む、ThinkPHP クラスライブラリ仕様に準拠したシステムクラスライブラリを指します。コア基本クラスライブラリディレクトリはシステムの Lib ディレクトリにあり、拡張基本クラスライブラリは Extend/Library ディレクトリにあり、ORG および Com 拡張クラスライブラリを拡張できます。。コア基本クラスライブラリの役割は、次のようなフレームワークの汎用開発を完了するために必要な基本クラスと組み込みサポートクラスを完成させることです。

クラス名	説明
アクション	システム基本コントローラークラス
アプリ	システムアプリケーションクラス
行動	システム動作基礎クラス
キャッシュ	システムキャッシュクラス
DB	システム抽象データベースクラス
派遣者	URLスケジュールクラス
ログ	システムログクラス
モデル	システム基本モデルクラス
考える	システムエントリと静的クラス
ThinkException	システム基本例外クラス
見る	クラスを見る
ウィジェット	システムウィジェット基本クラス

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

ディレクトリ	呼び出しパス	説明
リブ/アクション	@.アクションまたは自動ロード	コントローラークラスライブラリパッケージ
ライブラリ/モデル	@.Model または自動ロード	モデルクラスライブラリパッケージ
リブ/行動	メソッド B を使用して自動的に呼び出すかロードします	アプリケーション動作ライブラリパッケージ
ライブラリ/ウィジェット	Wメソッドを使用してテンプレート内で呼び出す	ウィジェットクラスライブラリパッケージを適用する

クラスライブラリのインポート

1. 明示的なインポート

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

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

上記の 2 つのメソッドは、Think 基本クラスライブラリの Util/Session.class.php ファイルと ORG 拡張クラスライブラリパッケージの Util/Page.class.php ファイルをそれぞれインポートします。

名前空間インポートメソッドに加えて、インポートメソッドでもエイリアスインポートをサポートできます。エイリアスインポートを使用するには、まずプロジェクト構成ディレクトリにエイリアスを追加して、必要なクラスライブラリエイリアスを定義する必要があります。たとえば、プロジェクトで使用されます:

サードパーティのクラスライブラリは、システム拡張ディレクトリの下の Vendor ディレクトリに一律に配置され、ベンダーメソッドを使用してインポートされます。ただし、パラメータはデフォルト値が変更されている点を除き、インポートメソッドと同じです。たとえば、Vendor ディレクトリの下に Zend の FilterDir.php を配置します。このとき、Dir ファイルのパスは次のようになります。 VendorZendFilterDir.php では、ベンダーメソッドを使用してインポートして使用します:

ほとんどの場合、クラスライブラリを手動でインポートする必要はありませんが、構成を通じて自動ロードメカニズムを使用できます。これにより、パフォーマンスが大幅に向上します。自動ロードには、ロードの優先順位に応じて、エイリアスの自動ロード、システムルールの自動ロード、カスタムパスの自動ロードの 3 つの状況があります。

2. システムルールは自動的にロードされます

クラス名	ルール	説明
行動カテゴリー	ルール1	システムクラスライブラリディレクトリの下のBehaviorディレクトリを検索します
	ルール 2	システム拡張ディレクトリの下の Behavior ディレクトリを検索します
	ルール 3	アプリケーションライブラリディレクトリの下でBehaviorディレクトリを検索します
	ルール 4	スキーマ拡張が有効な場合は、スキーマ拡張ディレクトリの下の Behavior ディレクトリを検索します
モデルクラス	ルール1	グループ化が有効な場合は、アプリケーションクラスライブラリディレクトリのモデル/現在のグループディレクトリを検索します
	ルール 2	アプリケーションクラスライブラリの下のModelディレクトリを検索します
	ルール 3	システム拡張ディレクトリの下の Model ディレクトリを検索します
コントローラークラス	ルール1	グループ化が有効な場合は、アプリケーションクラスライブラリディレクトリのアクション/現在のグループディレクトリを検索します
	ルール 2	プロジェクトのクラスライブラリディレクトリの下にあるアクションディレクトリを検索します
	ルール 3	システム拡張ディレクトリの下のアクションディレクトリを検索します

3. カスタムパスの自動読み込み

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

コントローラー:

1. URLパターン

1. 通常モード

http://サーバー名/アプリ名/?m=module&a=action&id=1

2. PATHINFO モード (デフォルトモード)

: URL_MODEL を 1 に設定します

PATHINFO モードはデフォルトで使用され、柔軟で使いやすい URL サポートを提供します。 PATHINFO モードは、

http://サーバー名/アプリ名/module/action/id/1/または

http://サーバー名/アプリ名/モジュール,アクション,ID,1/

3. REWRITE モード

4. 互換モード

ディスパッチャーは、URLに基づいて現在のプロジェクト、グループ(定義されている場合)モジュール、オペレーション、および実行する必要があるその他のパラメータを取得します。場合によっては、プロジェクト名が URL アドレスに表示されない場合があります (通常、エントリファイルは特定のプロジェクトを表し、エントリファイルは非表示にすることができます)。
各モジュールはコントローラークラスであり、通常はプロジェクトの LibAction ディレクトリの下にあります。

バージョン 3.1 以降、操作メソッドのサフィックスを設定するための ACTION_SUFFIX 構成パラメータが追加されました。

アプリケーションがデータベースと対話する必要がない場合、モデルクラスを定義する必要はありませんが、アクションコントローラーを定義する必要があります。アクションコントローラーは通常、プロジェクトの Lib/Action ディレクトリの下にあります。

クラス UserAction は Action を拡張します{}

コントローラーファイルの名前はUserAction.class.phpです。

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

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

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

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

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

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

詳細については、こちらをご覧ください: http://doc.thinkphp.cn/manual/url_route.html

詳細については、こちらをご覧ください: http://doc.thinkphp.cn/manual/url_rewrite.html<code><code><code><code><code><code><code><code><code><code><code><code>

8. URLの生成

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

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

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

U('User/add') // Userモジュールの追加操作のURLアドレスを生成します
U('Blog/read?id=1') // ブログモジュールの読み取り操作とID 1のURLアドレスを生成します
U('Admin/User/select') // AdminグループのUserモジュールのselectオペレーションのURLアドレスを生成します

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

U('ブログ/cate',array('cate_id'=>1,'status'=>1))
U('ブログ/カテゴリー','cate_id=1&status=1')
U('ブログ/cate?cate_id=1&status=1')

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

U('ブログ/cate/cate_id/1/status/1')

U('Blog/read?id=1') は例です。

'news/:idd'=>'ニュース/読む'

う('/news/1')

http://サーバー名/index.php/news/1

注: テンプレートファイル内で U メソッドを直接使用する場合は、{:U('パラメータ 1', 'パラメータ 2'...)} を使用する必要があります。詳細については、「8.3 テンプレートエンジンでの関数の使用」を参照してください。章。

アプリケーションに複数のサブドメインの操作アドレスが含まれる場合は、U メソッドでアドレスを生成する必要があるドメイン名を指定することもできます。例: <code>

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

<code>@ 指定する必要があるドメイン名を渡すだけです。

さらに、U メソッドの 5 番目のパラメーターが true に設定されている場合、現在のドメイン名が自動的に認識され、現在のアドレスのサブドメイン名がサブドメイン名の展開設定 APP_SUB_DOMAIN_DEPLOY および APP_SUB_DOMAIN_RULES に基づいて自動的に生成されることを意味します。。
URL_CASE_INSENSITIVE がオンになっている場合、小文字の URL アドレスが均一に生成されます。

9. URLケース

'URL_CASE_INSENSITIVE' =>true

<code>URL アクセスで大文字と小文字が区別されなくなっていることがわかります。

ここで注意すべき点は、UserTypeAction のモジュールクラスを定義する場合、URL アクセスは次のようにする必要があるということです: <code>

http://サーバー名/index.php/user_type/list
//
http://サーバー名/index.php/usertype/list

<code>利用系统提供的U方法可以为你自动生成相关的URL地址。
如果设置<code>システムが提供する U メソッドを使用して、関連する URL アドレスを自動的に生成します。
設定されている場合

<code>的话，URL就又变成：<code>

<code>

注: URL の大文字と小文字の区別はシステムの命名規則を変更しません。システムの命名規則に従うことによってのみ、URL の大文字と小文字の区別を正しく実装できます。

システムは、現在の操作に前操作と後操作があるかどうかを検出し、それらが存在する場合は、前操作と後操作のメソッド名をメソッドの前に追加します。実行されます。例:

クラス CityAction は Action{
//事前操作方法
パブリック関数 _before_index(){
echo 'before
';
}
パブリック関数index(){
echo 'index
';
}
//操作後のメソッド
パブリック関数 _after_index(){
echo 'after
';
}
}

どのような操作メソッドでも、このようなルールに従って事前メソッドと事後メソッドを定義できます。

現在の操作で操作メソッドが定義されていないが、テンプレートファイルを直接レンダリングする場合でも、事前メソッドと事後メソッドが定義されていれば、その操作は引き続き有効になります。実際のテンプレート出力は現在の操作のみであり、通常、前操作と後操作には出力がありません。
一部のメソッドで終了またはエラー出力が使用されている場合、ポストメソッドが実行されなくなる可能性があることに注意してください。
たとえば、システムアクションのエラーメソッドが現在のオペレーションで呼び出された場合、ポストオペレーションは実行されませんが、成功メソッドのポストメソッドの実行は影響を受けません。

11. モジュール間通話

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

クラス IndexAction は Action{
パブリック関数index(){
// UserAction をインスタンス化する
$User = new UserAction();
//その他のユーザー操作
//...
$this->display() //出力ページテンプレート
}

システムはアクションコントローラーを自動的にロードするため、UserAction クラスをインポートせずに直接インスタンス化できます。 そして、モジュール間の呼び出しを容易にするために、システムには A メソッドと R メソッドが組み込まれています。
$User = A('User');

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

実際、メソッド A はグループ間またはプロジェクト間の呼び出しもサポートしており、デフォルトでは、現在のプロジェクトの下にあるモジュールが呼び出されます。
A('[プロジェクト名://][グループ名/]モジュール名')
例:

A('Admin://User') //Admin プロジェクトの User モジュールの呼び出しを示します

R('User/info') //現在のプロジェクトの User モジュールの info 操作メソッドの呼び出しを示します
R('Admin/User/info') //AdminグループのUserモジュールのinfo操作メソッドの呼び出しを示します
R('Admin://Tool/User/info') //AdminプロジェクトのToolグループのUserモジュールのinfo操作メソッドの呼び出しを示します

を拡張します

<code><code><code>システムの Action クラスには、success と error という 2 つの組み込みジャンプメソッドがあり、ページジャンププロンプトに使用され、ajax 送信をサポートできます。使用方法は非常に簡単です。例:

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

if($result){
//設定が成功した後にジャンプするページのアドレスを設定します。デフォルトの戻りページは $_SERVER['HTTP_REFERER'] です。
成功メソッドとエラーメソッドには対応するテンプレートがあり、設定可能です。デフォルト設定では、両方のメソッドに対応するテンプレートは次のとおりです。

//対応するテンプレートファイルはデフォルトで正常にジャンプされます
'TMPL_ACTION_SUCCESS' => 'Tpl/dispatch_jump.tpl';
プロジェクト内でテンプレートファイルを使用することもできます
//デフォルトのエラージャンプに対応するテンプレートファイル

//対応するテンプレートファイルはデフォルトで正常にジャンプされます
'TMPL_ACTION_SUCCESS' => 'パブリック:成功';
テンプレートファイルではテンプレートタグを使用でき、次のテンプレート変数を使用できます。

$this->assign('var1','value1');
$this->assign('var2','value2');
$this->error('パラメータが間違っています','ジャンプするURLアドレス');

13. リダイレクト

//新しいモジュールのカテゴリ操作にリダイレクトします
$this->redirect('New/category', array('cate_id' => 2), 5, 'ページジャンプ...');

	$メッセージ
	$ステータス

声明：

この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

前の記事：画像にテキスト透かしを追加するための PHP オブジェクト指向およびプロセス指向のメソッド、_PHP チュートリアル次の記事：画像にテキスト透かしを追加するための PHP オブジェクト指向およびプロセス指向のメソッド、_PHP チュートリアル

続きを見る

ThinkPHP-3.1、thinkphp-3.1_PHP チュートリアル