Yii のクイックスタート (1)
- 黄舟オリジナル
- 2016-12-20 11:07:221278ブラウズ
転載する場合は出典を明記してください: Yii Quick Start (1)
Ⅰ. 基本概念
1. エントリーファイル
エントリーファイルの内容: 一般的な形式は次のとおりです:
$yii=dirname(__FILE__).'/../../framework/yii.php ';/ /Yii フレームワークの場所
$config=dirname(__FILE__).'/protected/config/main.php';// 現在のアプリケーションのメイン設定ファイルの場所
// 正式な環境をデプロイするときは、次の行
//define('YII_DEBUG') またはdefine('YII_DEBUG',true);//デバッグモードで実行するかどうか
require_once($yii);//Yiiフレームワークが含まれています
Yii::createWebApplication($config )->run ();//メイン構成ファイルに基づいてアプリケーション インスタンスを作成し、実行します。現在のアプリケーションのどこからでも Yii::app() を介してこのインスタンスにアクセスできます。
2. メイン設定ファイル
保存場所: your application/protected/config/main.php
ファイルの内容: 一般的な形式は次のとおりです:
return array(
'basePath'=>dirname (__FILE__ ).DIRECTORY_SEPARATOR.'..', //現在のアプリケーションのルートディレクトリの絶対物理パス
'name'=>'Yii Blog Demo', //現在のアプリケーションの名前
//アプリケーション コンポーネントをログ (記録) します。これは、アプリケーション コンポーネントがアクセスされたかどうかに関係なく作成されることを意味します。
'preload'=>array( 'log'), //log はコンポーネント ID です
//自動ロードされたモデルとコンポーネント クラス
'import'=>array(
'application.models.*', //「application/models/」をロードします" フォルダー すべてのモデル クラス
'application.components.*', //すべてのアプリケーション コンポーネント クラスを「application/components/」フォルダーにロードします
),
'defaultController'=>'post', // デフォルトを設定しますcontrol Device class
// 現在のアプリケーションのコンポーネント構成。その他の構成コンポーネントについては、以下の「コア アプリケーション コンポーネント」を参照してください
'components'=>array(
'user'=>array( //user( User)コンポーネントの構成、「ユーザー」はコンポーネントID // Cookieベースの認証を使用できます。 、、、、、、、 'port' =＆gt; MySQL データベースを使用する場合は、次のコメントを解除してください
'errorHandler'=> Array (// を使用して、SiteController コントローラー クラスの ActionError メソッドを使用してエラーを表示します
'erraraction' = & gt; 'site/ error', // エラーが発生した場合は、操作を実行します。コントローラー名とメソッド名はすべて小文字で、スラッシュ「/」で区切られています
),
//URL ルーティング マネージャー
'urlManager'=>array(
)'urlFormat'=>'path', //URL 形式。 2 つの形式がサポートされています: 「path」形式 (/path/to/EntryScript.php/name1/value1/name2/value2... など) と「get」形式 (/path/to/EntryScript.php など) ? 名前1=値1&名前2=値2...)。 「パス」形式を使用する場合は、次のルールを設定する必要があります:
'rules'=>array( //URL rules. 構文: <パラメータ名: 正規表現>
>/
'
),
),
'log'=>array( //记录
'class'=>'CLogRouter' //处理记录情報的类
' ルート'=>array(
-'s' s 's - −-- to）を使用して、
/ウェブページにエラーログメッセージを表示する場合は、以下のWebページに表示される以下の
['パラメーター名 ' ] は、アプリケーション層のパラメーターにアクセスできます
'params'=>require(dirname(__FILE__).'/params.php'),
);
コア アプリケーション コンポーネント:
Yii が事前に定義した一連のコア アプリケーション コンポーネントが提供します一般的な Web アプリケーションで使用される機能。たとえば、リクエスト コンポーネントは、ユーザー リクエストを解析し、URL や Cookie などの情報を提供するために使用されます。これらのコアコンポーネントのプロパティを設定することで、Yii のデフォルトの動作をほぼ任意に変更できます。
以下に、CWebApplication によって事前定義されたコア コンポーネントをリストします。
assetManager: CAssetManager - プライベートアセットファイルのリリースを管理します。
authManager: CAuthManager - ロールベースのアクセス制御 (RBAC) を管理します。
cache: CCache - データ キャッシュ機能を提供します。実際のクラス (CMemCache、CDbCache など) を指定する必要があることに注意してください。それ以外の場合、このコンポーネントにアクセスすると NULL が返されます。
clientScript: CClientScript - クライアント側スクリプト (JavaScript および CSS) を管理します。
coreMessages: CPhpMessageSource - Yii フレームワークで使用されるコアメッセージの翻訳を提供します。
db: CDbConnection - データベース接続を提供します。このコンポーネントを使用するには、その connectionString プロパティを設定する必要があることに注意してください。
errorHandler: CErrorHandler - 捕捉されなかった PHP エラーと例外を処理します。
format: CFormatter - フォーマットされた数値表示。この機能はバージョン 1.1.0 以降で利用可能です。
messages: CPhpMessageSource - Yii アプリケーションで使用されるメッセージ翻訳を提供します。
request: CHttpRequest - ユーザーのリクエストに関する情報を提供します。
securityManager: CSecurityManager - ハッシュ、暗号化などのセキュリティ関連サービスを提供します。
session: CHttpSession - セッション関連の機能を提供します。
statePersister: CStatePersister - グローバル状態永続メソッドを提供します。
urlManager: CUrlManager - URL 解析および作成関連の機能を提供します。
user: CWebUser - 現在のユーザーの識別情報を提供します。
themeManager: CThemeManager - テーマを管理します。
アプリケーションコンポーネントにアクセスするには、Yii::app()->コンポーネントのIDを使用します
3.コントローラー(Controller)
ControllerはCControllerクラスのサブクラスのインスタンスです。ユーザーの要求に応じてアプリケーションによって作成されます。コントローラーが実行されると、要求されたアクション (コントローラー クラス メソッド) が実行され、通常は必要なモデルが導入され、対応するビューがレンダリングされます。アクションは、名前が action で始まるコントローラー クラスのメソッドです (アクション + 大文字のアクション名)。
コントローラークラスファイルの格納場所はprotected/controllers/
コントローラーとアクションはIDで識別されます。
コントローラー ID は、「親ディレクトリ/サブディレクトリ/コントローラー名」の形式で、対応するコントローラー クラス ファイル protected/controllers/親ディレクトリ/サブディレクトリ/大文字のコントローラー名に対応します。
アクション ID は、アクションメソッド名からアクションプレフィックスを除いたもの。
1. ルーティング
ユーザーはルーティングの形式で特定のコントローラーとアクションをリクエストします。ルートは、スラッシュで区切られたコントローラー ID とアクション ID によって接続されます。
たとえば、post/edit ルートは PostController とその編集アクションを表します。デフォルトでは、URL http://hostname/index.php?r=post/edit はこのコントローラとアクションをリクエストします。
注: デフォルトでは、ルートは大文字と小文字が区別されます。アプリケーション構成で CUrlManager::caseSensitive を false に設定することで、ルーティングで大文字と小文字を区別しないようにできます。大文字と小文字を区別しないモードでは、コントローラー クラス ファイルを含むディレクトリ名は小文字であり、コントローラー マップとアクション マップで使用されるキーは小文字であるという規則に従っていることを確認してください。
ルーティングの形式: コントローラー ID/アクション ID またはモジュール ID/コントローラー ID/アクション ID (ネストされたモジュールの場合、モジュール ID は親モジュール ID/サブモジュール ID)
2. コントローラーのインスタンス化
アプリケーションは使用します。次のルールによってコントローラー クラスとクラス ファイルの場所が決定されます:
1. CWebApplication::catchAllRequest が指定されている場合、コントローラーはこの属性に基づいて作成され、ユーザー指定のコントローラー ID は無視されます。これは通常、アプリケーションをメンテナンス状態にし、静的なプロンプト ページを表示するために使用されます。
2. ID が CWebApplication::controllerMap で見つかった場合、対応するコントローラー設定を使用してコントローラー インスタンスが作成されます。
3. ID が「path/to/xyz」の形式の場合、コントローラークラス名は XyzController と判断され、対応するクラスファイルは protected/controllers/path/to/XyzController.php となります。 。クラス ファイルが存在しない場合、404 CHttpException がトリガーされます。
モジュールを使用する場合、アプリケーションはこの ID がモジュール内のコントローラーを表すかどうかを確認します。その場合、モジュール インスタンスが最初に作成され、次にモジュール内のコントローラー インスタンスが作成されます。
3. アクション
アクションは、アクションという単語を接頭辞として持つ名前のメソッドとして定義されます。より高度な方法は、アクション クラスを定義し、リクエストの受信時にコントローラーにそのクラスをインスタンス化させることです。これによりアクションを再利用できるようになり、再利用性が向上します。アニメーション 1、アクション クラスを定義します。基本的な形式は次のとおりです:
Class UpdateAction Extends Caction
{
Public Function Run () {
// ここにアクション ロジックを配置します
}}}}}}}}}:このアクションに注意して、次の方法でコントローラー クラスの events() メソッドをオーバーライドする必要があります:
class PostController extends CController
{
public functionactions()
{
使用する - .post.UpdateAction', //使用編集アクションを処理するための「Application Folder/controllers/post/UpdateAction.php」ファイル内のクラス
);
}
}
上記のように、パス エイリアス「application .controllers.post.UpdateAction」を使用して、アクション クラス ファイルは「protected/controllers/post/UpdateAction.php」です。
クラスベースのアクションを記述することで、アプリケーションをモジュール スタイルに編成できます。たとえば、次のディレクトリ構造を使用して、コントローラ関連のコードを整理できます:
protected/
controllers/
PostController.php
UserController.php
post/
CreateAction.php
ReadAction.php
ListAction.php
ProfileAction.php
ListAction。フィルターは、コントローラーのアクションの前または後に実行するように構成できるコードの一部です。
アクションには複数のフィルターを含めることができます。複数のフィルターがある場合、それらはフィルター リストに表示される順序で実行されます。フィルターにより、アクションや後続の他のフィルターの実行が妨げられる場合があります。
フィルターはコントローラークラスのメソッドとして定義できます。フィルター メソッド名は filter で始まる必要があります。たとえば、既存の filterAccessControl メソッドは、accessControl という名前のフィルターを定義します。フィルター メソッドは次の構造を持つ必要があります:
public function filterAccessControl($filterChain)
{
// $filterChain->run() を呼び出して、後続のフィルターとアクションの実行を続行します。
}
$filterChain (フィルター チェーン) は、要求されたアクションに関連するフィルターのリストを表す CFilterChain のインスタンスです。 filter メソッド内で $filterChain->run() を呼び出して、後続のフィルターとアクションの実行を続けることができます。
アクションと同様に、フィルターも CFilter またはそのサブクラスのインスタンスであるオブジェクトにすることができます。次のコードは、新しいフィルター クラスを定義します。
class PerformanceFilter extends CFilter
{
protected function preFilter($filterChain)
{
using using using using using using using using ‐ ‐ オフライン ‐ ‐ of, , ここで、return false
}
Proteable Function Postfilter ($ Filterchain) {
// アクション実行後のアプリケーションのロジックはアクション アプリケーション フィルターに適用されるため、 ccontroller :: filers () メソッドをカバーする必要があります。このメソッドはフィルター構成の配列を返す必要があります。例:
class PostController extends CController
{
…
public function filters()
{
return array(
これはメソッドベースのフィルターです)
array( //フィルターを構成するために配列が使用されます
'アプリケーション。 filters.PerformanceFilter - edit, create', //application.filters.PerformanceFilter フィルターを編集と作成以外のものに適用します (これはオブジェクトベースのフィルターです) を除くすべてのアクション
'unit'=>'second', // 初期化2 番目のフィルター オブジェクトのユニット属性値
),
); postOnly と PerformanceFilter の 2 つのフィルターが指定されています。 postOnly フィルターはメソッドベースです (対応するフィルター メソッドは CController で定義されています)。一方、performanceFilter フィルターはオブジェクトベースです。パス エイリアス application.filters.PerformanceFilter は、フィルター クラス ファイルが protected/filters/PerformanceFilter であることを指定します。 PerformanceFilter を配列で構成して、フィルター オブジェクトのプロパティ値の初期化に使用できるようにします。ここでは、PerformanceFilter の単位属性値が秒に初期化されます。
プラス記号とマイナス記号を使用して、どのアクションにフィルターを適用するか、または適用しないかを指定できます。上記のコードでは、postOnly は編集と作成のアクションにのみ適用する必要があり、PerformanceFilter は編集と作成以外のアクションに適用する必要があります。フィルター設定でプラス記号またはマイナス記号が使用されていない場合、このフィルターはすべてのアクションに適用されます。
5. モデル (Model)
モデルは CModel またはそのサブクラスのインスタンスです。モデルは、データとそれに関連付けられたビジネス ロジックを保持するために使用されます。
モデルは別個のデータオブジェクトです。データ テーブル内の行、またはユーザーが入力したフォームにすることができます。
データ オブジェクトの各フィールドはモデルの属性に対応します。各属性にはラベルがあり、一連のルールによって検証できます。
Yii はフォームモデルとアクティブレコードの 2 種類のモデルを実装します。どちらも同じ基本クラス CModel を継承しています。
フォーム モデルは CFormModel のインスタンスです。フォーム モデルは、ユーザーの入力から取得したデータを保持するために使用されます。このデータは多くの場合、取得、使用され、その後破棄されます。たとえば、ログイン ページでは、フォーム モデルを使用して、エンド ユーザーが提供したユーザー名とパスワードの情報を表すことができます。
アクティブ レコード (AR) は、オブジェクト指向スタイルでデータベース アクセスを抽象化するための設計パターンです。各 AR オブジェクトは、CActiveRecord のインスタンスまたはそのサブクラスの 1 つです。データテーブル内の行を表します。行のフィールドは、AR オブジェクトのプロパティに対応します。
6. ビュー
ビューは、主要なユーザー インタラクション要素を含む PHP スクリプトです。ビューには名前があり、レンダリング時にビュー スクリプト ファイルを識別するために使用されます。ビューの名前は、ビュー スクリプト名と同じです。例: edit ビューの名前は、edit.php という名前のスクリプト ファイルから取得されます。レンダリングするには、ビューの名前を渡して CController::render() を呼び出します。このメソッドは、「protected/views/controller ID」ディレクトリで対応するビュー ファイルを検索します。
ビュー スクリプト内で、$this を通じてコントローラー インスタンスにアクセスできます。 「$this->プロパティ名」を使用して、ビュー内のコントローラーの任意のプロパティを取得できます。
次のプッシュ メソッドを使用してデータをビューに渡すこともできます:
$this->render('edit', array(
'var1'=>$value1,
'var2'=>$value2,
));
上記のメソッドでは、 render() メソッドが配列の 2 番目のパラメーターを変数に抽出します。この結果、ビュー スクリプトで変数 $var1 と $var2 に直接アクセスできるようになります。
1. レイアウト
レイアウトは、ビューを変更するために使用される特別なビュー ファイルです。通常、ユーザー インターフェイス ビューの共通部分が含まれています。たとえば、レイアウトにはヘッダー部分とフッター部分を含めて、その間にコンテンツを埋め込むことができます。
...ここにヘッダー...
...ここにフッター...
$content は、コンテンツ ビューのレンダリング結果を格納します。
render() を使用すると、レイアウトが暗黙的に適用されます。ビュー スクリプト protected/views/layouts/main.php がデフォルトのレイアウト ファイルです。これは、CWebApplication::layout を変更することでカスタマイズできます。レイアウトなしでビューをレンダリングするには、 renderPartial() を呼び出します。
2. ウィジェット
ウィジェットは、CWidget またはそのサブクラスのインスタンスです。主にデータを表現するために使用されるコンポーネントです。ウィジェットは多くの場合、複雑で独立したユーザー インターフェイスを作成するためにビューに埋め込まれます。たとえば、カレンダー ウィジェットを使用して、複雑なカレンダー インターフェイスをレンダリングできます。ギズモにより、ユーザー インターフェイスがより再利用可能になります。
次のようにウィジェットを使用できます:
beginWidget('ウィジェット クラスのパス エイリアス'[,'属性初期化値を含む配列']) ?>
...コンテンツ本体ウィジェットによって取得できます...
endWidget(); ?>
または
widget('ウィジェットクラス パスエイリアス '[, '属性の初期化値を含む配列']); ?>
後者は、本文の内容を必要としないコンポーネントに使用されます。
ウィジェットを構成してパフォーマンスをカスタマイズできます。これは、CBaseController::beginWidget または CBaseController::widget を呼び出して初期化プロパティ値を設定することによって行われます。
これを行うには、これらのプロパティの初期化値を含む配列を渡します。配列のキーはプロパティの名前であり、配列の値は小さなオブジェクトのプロパティに対応する値です。以下に示すように:
$this->widget('CMaskedTextField',array(
'mask'=>'99/99/9999'
));
?>
CWidget を継承してオーバーライドするその init() メソッドと run() メソッドは新しいウィジェットを定義できます:
class MyWidget extends CWidget
{
public function init()
{
// このメソッドは CController::beginWidget() によって呼び出されます
}
public function run()
// このメソッドは CController によって呼び出されます。 :endWidget()
}
}
ウィジェットはコントローラーと同様に独自のビューを持つことができます。
デフォルトでは、小さなオブジェクトのビュー ファイルは、小さなオブジェクト クラス ファイルのディレクトリを含むビュー サブディレクトリ (protected/components/views) の下にあります。これらのビューは、コントローラーと同様に、CWidget::render() を呼び出すことでレンダリングできます。唯一の違いは、ウィジェットのビューがレイアウト ファイルをサポートしていないことです。さらに、ウィジェット ビューの $this は、コントローラー インスタンスではなくウィジェット インスタンスを指します。
3. システムビュー
システムビューのレンダリングは通常、Yii のエラーとログ情報を表示するために使用されます。
システム ビューの名前付けは、いくつかのルールに従います。たとえば、「errorXXX」のような名前は、エラー番号 XXX の CHttpException を示すビューをレンダリングするために使用されます。たとえば、CHttpException が 404 エラーをスローした場合、error404 が表示されます。
framework/views の下に、Yii は一連のデフォルトのシステムビューを提供します。それらは protected/views/system の下に同じ名前のビューファイルを作成することでカスタマイズできます。
7. コンポーネント
Yii アプリケーションはコンポーネント上に構築されます。コンポーネントは、CComponent またはそのサブクラスの 1 つのインスタンスです。コンポーネントの使用には、主にそのプロパティへのアクセスと、いつトリガーまたは処理するかが含まれます。基本クラス CComponent は、プロパティとイベントの定義方法を指定します。
1. コンポーネントのプロパティ
コンポーネントのプロパティは、オブジェクトのパブリック メンバー変数に似ています。読み取りと書き込みが可能です。
コンポーネントのプロパティを定義するには、コンポーネント クラスでパブリック メンバー変数を定義するだけです。
より柔軟な方法は、ゲッター メソッドとセッター メソッドを定義することです。例:
public function getTextWidth() // textWidth プロパティを取得します
{
return $this->_textWidth;
}
public function setTextWidth($value) // TextWidth プロパティを設定します
{
$this->_textWidth=$value ;
}
上記のコードは、textWidth という名前の書き込み可能なプロパティを定義しています (名前は大文字と小文字が区別されません)。プロパティが読み取られるときは getTextWidth() が呼び出され、その戻り値がプロパティ値になります。同様に、プロパティが書き込まれるときは setTextWidth() が呼び出されます。 setter メソッドが定義されていない場合、プロパティは読み取り専用となり、書き込まれると例外がスローされます。 getter メソッドと setter メソッドを使用してプロパティを定義する利点の 1 つは、プロパティの読み取りまたは書き込み時に追加のロジック (検証の実行、イベントのトリガーなど) を実行できることです。
注: ゲッター/セッターを通じて定義されたプロパティとクラス メンバー変数の間には微妙な違いがあります。プロパティ名は大文字と小文字が区別されませんが、クラス メンバー変数は大文字と小文字が区別されます。
2. コンポーネント イベント
コンポーネント イベントは、イベント ハンドラーと呼ばれるメソッドを値として使用する特別なプロパティです。イベントにメソッドを割り当てると、イベントが発生したときにそのメソッドが自動的に呼び出されます。したがって、コンポーネントの動作は、コンポーネント開発中に予期しない方法で変更される可能性があります。
コンポーネントイベントは、onで始まる名前で定義されます。 getter/setter メソッドを通じて定義されたプロパティと同様、イベント名では大文字と小文字が区別されません。次のコードは、onClicked イベントを定義します:
public function onClicked($event)
{
$this->raiseEvent('onClicked', $event);
}
$event (イベント パラメーターとして) ここでは CEvent またはそのサブクラス インスタンスです。 。
次のようにこのイベントにメソッドを割り当てることができます:
$component->onClicked=$callback;
ここで、$callback は有効な PHP コールバックを指します。グローバル関数またはクラス内のメソッドにすることができます。後者の場合は、array($object,'methodName') のように配列として指定する必要があります。
イベント ハンドルの構造は次のとおりです。
関数メソッド名 ($event)
{
…
}
ここでの $event は、イベントを説明するパラメーターです (raiseEvent() 呼び出しから取得されます)。 $event パラメータは、CEvent またはそのサブクラスの 1 つのインスタンスです。少なくとも、誰がイベントをトリガーしたかに関する情報が含まれています。
イベント ハンドラーは、PHP 5.3 以降でサポートされる匿名関数にすることもできます。例:
$component->onClicked=function($event) {
…
}
ここで onClicked() を呼び出すと、onClicked イベントが (onClicked() 内で) トリガーされ、添付されたイベントのハンドルが自動的に呼び出されます。
イベントは複数のハンドルにバインドできます。イベントが発生すると、これらのハンドラーはイベントにバインドされた順序で実行されます。ハンドラーが後続のハンドラーの実行を禁止すると決定した場合、$event->handled を true に設定します。
3. コンポーネントの動作
このコンポーネントは mixin のサポートを追加し、1 つ以上の動作をバインドできます。ビヘイビアーは、特殊な継承 (つまり、通常のクラスの継承) ではなく、関数を収集することによってバインドされているコンポーネントによってメソッドを継承できるオブジェクトです。コンポーネントは、「多重継承」を通じて複数の動作のバインディングを実装できます。
Behavior クラスは IBehavior インターフェイスを実装する必要があります。 ほとんどの動作は CBeavior から継承できます。動作をモデルにバインドする必要がある場合は、モデル専用のバインド プロパティを実装する CModelBehavior または CActiveRecordBehavior から継承することもできます。
ビヘイビアーを使用するには、まずこのビヘイビアーのattach() メソッドを呼び出してコンポーネントにバインドする必要があります。次に、コンポーネントを通じてこの動作メソッドを呼び出すことができます:
// $name はコンポーネント内の動作を一意に識別します
$component->attachBehavior($name,$behavior);
// test() は動作メソッド内にあります。
$component->test();
バインドされた動作は、コンポーネント内の通常のプロパティと同様にアクセスできます。たとえば、tree という名前のビヘイビアーがコンポーネントにバインドされている場合、次のコードを通じてこのビヘイビアーへの参照を取得できます。
$behavior=$component->tree;
// は次のコードと同じです:
// $behavior=$component->asa('tree');
現時点では、この動作を一時的に禁止できますそのメソッドはコンポーネント内で失敗します。例:
$component->disableBehavior($name);
// 次のコードは例外をスローします
$component->test();
$component->enableBehavior($name);
//今すぐ使用できます
$component->test();
同じ名前の 2 つの動作を同じコンポーネントにバインドすることができます。この場合、最初にバインドするアクションが優先されます。
ビヘイビアーはイベントと併用するとさらに強力になります。ビヘイビアーがコンポーネントにバインドされている場合、ビヘイビア内の一部のメソッドをコンポーネントの一部のイベントにバインドできます。このようにして、動作を有機的に観察したり、コンポーネントの通常の実行フローを変更したりできます。
ビヘイビアーのプロパティには、ビヘイビアがバインドされているコンポーネントを通じてアクセスすることもできます。これらのプロパティには、パブリック メンバー変数と、ゲッターやセッターを介して設定されたプロパティが含まれます。たとえば、ビヘイビアーにプロパティ xyz があり、このビヘイビアーがコンポーネント $a にバインドされている場合、式 $a->xyz を使用してこのビヘイビアーのプロパティにアクセスできます。
8. モジュール
モジュールは、モデル、ビュー、コントローラー、その他のサポート コンポーネントを含む独立したソフトウェア ユニットです。多くの点で、モジュールはアプリケーションに似ています。主な違いは、モジュールは個別にデプロイできず、アプリケーション内に存在する必要があることです。ユーザーは、通常のアプリケーションのコントローラーにアクセスするのと同じように、モジュール内のコントローラーにアクセスできます。
モジュールはいくつかのシナリオで役立ちます。大規模なアプリケーションの場合は、アプリケーションを複数のモジュールに分割する必要がある場合がありますが、各モジュールは独立して保守およびデプロイできます。ユーザー管理やコメント管理などの一部の共通機能はモジュールの形式で開発できるため、将来のプロジェクトで簡単に再利用できます。
1. モジュールを作成します
モジュールはディレクトリ内に編成され、ディレクトリ名はモジュールの一意の ID になります。モジュール ディレクトリの構造は、アプリケーションのベース ディレクトリと非常によく似ています。 Fourm モジュールの一般的なディレクトリ構造は以下のとおりです:
フォーラム/モジュールフォルダー
forummodule.php モジュールファイル
コンポーネント/再利用されたユーザーコンポーネントを含む
小さなオブジェクトを含むビュー
コントローラー/コントローラークラスファイルを含む
DefaultController.php デフォルトのコントローラークラスファイルextensions拡張/サードパーティ拡張機能の含まれる
モデル/モデルクラスファイルを含む
ビュー/コントローラービューとレイアウトファイルを含むcowebmoduleを使用してファイルを使用してビューを使用できます。クラスの名前は式 ucfirst($id).'Module' によって決定されます。$id はモジュールの ID (またはモジュールのディレクトリ名) を表します。モジュール クラスは、モジュール コード間で共有できる情報を保存する中心的な場所です。たとえば、CWebModule::params を使用してモジュール パラメーターを保存し、CWebModule::components を使用してモジュール レベルのアプリケーション コンポーネントを共有できます。
2. モジュールを使用する
モジュールを使用するには、まずアプリケーションのベース ディレクトリの modules フォルダーにモジュール ディレクトリを配置します。次に、アプリの modules 属性でモジュール ID を宣言します。たとえば、上記のフォーラム モジュールを使用するには、次のアプリケーション構成を使用できます:
return array(
...
'modules'=>array('forum',...),
… ..
);
モジュールは初期プロパティ値を使用して構成することもできます。このアプローチは、アプリケーション コンポーネントの構成と非常によく似ています。たとえば、フォーラム モジュールはモジュール クラスに postPerPage という名前のプロパティを持つことができ、これはアプリケーション構成で次のように構成できます:
return array(
...
'modules'=>array(
'forum '= >配列(
モジュール インスタンス内では、モジュール レベルで共有される情報にアクセスできます。たとえば、上記の postPerPage 情報にアクセスするには、次の式を使用できます:
$postPerPage=Yii::app()->controller->module->postPerPage;
// たとえば、$this は次を指します。コントロール コンテナー インスタンスでは、次のステートメントを使用できます
// $postPerPage=$this->module->postPerPage;
モジュール内のコントローラーアクションには、「モジュールID/コントローラーID/アクションID」または「モジュールID/コントローラークラスファイルが格納されているサブディレクトリ名/コントローラーID/アクションID」のルートでアクセスできます。たとえば、上記のフォーラム モジュールに PostController という名前のコントローラーがあると仮定すると、forum/post/create ルートを通じてこのコントローラーの作成アクションにアクセスできます。このルートに対応する URL は http://www.example.com/index.php?r=forum/post/create です。
3. ネストされたモジュール
モジュールは無限にネストできます。これは、あるモジュールに別のモジュールを含めることができ、この別のモジュールに他のモジュールを含めることができることを意味します。前者を親モジュール、後者をサブモジュールと呼びます。サブモジュールは、前にアプリケーション構成でモジュールを定義したのと同じように、親モジュールの modules 属性で定義する必要があります。
サブモジュール内のコントローラー アクションにアクセスするには、ルートの親モジュール ID/サブモジュール ID/コントローラー ID/アクション ID を使用する必要があります。
9. パスエイリアス
パスエイリアスは Yii で広く使用されています。パス エイリアスは、ディレクトリまたはファイルのパスに関連付けられます。これは、広く使用されている名前空間形式と同様のドット構文で指定されます:
RootAlias.path.to.target
ここで、RootAlias は既存のディレクトリのエイリアスです YiiBase::setPathOfAlias() を呼び出すことで、新しいディレクトリを定義できます。パスの別名。便宜上、Yii は以下のルートエイリアスを事前定義します:
system: Yii フレームワークディレクトリを表します;
application: アプリケーションのベースディレクトリを表します;
webroot: エントリスクリプトファイルが存在するディレクトリを表します。位置しています。
ext: すべてのサードパーティ拡張機能を含むディレクトリを表します。
さらに、アプリケーションがモジュールを使用する場合、(Yii) は各モジュール ID のルート エイリアスも定義し、対応するモジュールのルート ディレクトリを指します。
YiiBase::getPathOfAlias() を使用すると、エイリアスを対応するパスに変換できます。
エイリアスを使用すると、クラス定義を簡単にインポートできます。たとえば、CController クラスの定義をインクルードしたい場合は、次のコードを呼び出すことができます
Yii::import('system.web.CController');
インポート メソッドは include や require とは異なります。もっと効率的。インポートされたクラス定義は、初めて参照されるまで実際には組み込まれません。同じ名前空間を複数回インポートする場合も、include_once や require_once よりもはるかに高速になります。
次の構文を使用してディレクトリ全体をインポートすることもできます。これにより、このディレクトリ内のクラス ファイルが必要に応じて自動的に組み込まれます。
Yii::import('system.web.*');
インポートに加えて、エイリアスは他の多くの場所のクラスも指します。たとえば、パスエイリアスを Yii::createComponent() に渡して、対応するクラスのインスタンスを作成できます。クラス ファイルがこれまでにインクルードされたことがない場合でも。
パスのエイリアスと名前空間を混同しないでください。名前空間は、たとえ同じ名前であっても、クラス名の論理的な組み合わせを指します。パス エイリアスは、クラス ファイルまたはディレクトリを指すために使用されます。パスのエイリアスは名前空間と競合しません。
10. 開発仕様
以下では、Yii プログラミングにおける推奨開発仕様について説明します。簡単にするために、WebRoot が Yii アプリケーションがインストールされているディレクトリであると仮定します。
1. URL
デフォルトでは、Yii は次の形式の URL を認識します:
http://hostname/index.php?r=ControllerID/ActionID
r 変数は、Yii によってコントローラーおよびアクションとして解析できるルートを意味します。 ActionID が省略された場合、コントローラーはデフォルトのアクション (CController::defaultAction で定義) を使用します。ControllerID も省略された場合 (または r 変数が存在しない場合)、アプリケーションはデフォルトのコントローラー (CWebApplication::defaultController で定義) を使用します。 ）。
CUrlManager を使用すると、http://hostname/ControllerID/ActionID.html など、より識別可能で SEO に適した URL を作成できます。
2. コード
Yii では、変数、関数、クラスに名前を付けるときにキャメルケース スタイルを使用することをお勧めします。つまり、各単語の最初の文字を大文字にし、間にスペースを入れずに接続します。変数名と関数名は、クラス名と区別するために、最初の単語をすべて小文字にする必要があります。プライベート クラス メンバー変数の場合は、名前の前にアンダースコアを付けることをお勧めします (例: $_actionList)。
コントローラー クラス名の特別なルールは、コントローラーという単語で終わる必要があることです。この場合、コントローラー ID はクラス名の最初の文字が小文字になり、コントローラーという単語が削除されます。たとえば、PageController クラスの ID は page です。このルールにより、アプリケーションの安全性が高まります。また、コントローラー関連の URL も簡素化されます (例: /index.php?r=PageController/index の代わりに /index.php?r=page/index)。
3. 設定
設定はキーと値のペアの配列です。各キーは構成されたオブジェクト内のプロパティ名を表し、各値は対応するプロパティの初期値です。
クラス内の書き込み可能なプロパティはすべて設定できます。構成されていない場合、プロパティはデフォルト値を使用します。プロパティを構成するときは、ドキュメントを読んで初期値が正しいことを確認することをお勧めします。
4. ファイル
ファイルの名前付けと使用の規則は、その種類によって異なります。
クラス ファイルには、そのファイルに含まれるパブリック クラスにちなんで名前を付ける必要があります。たとえば、CController クラスは CController.php ファイルにあります。パブリック クラスは、他のクラスから使用できるクラスです。各クラス ファイルには、パブリック クラスを 1 つだけ含める必要があります。プライベート クラス (1 つのパブリック クラスでのみ使用できるクラス) は、それを使用するパブリック クラスと同じファイルに配置できます。
ビュー ファイルにはビューにちなんだ名前を付ける必要があります。たとえば、インデックス ビューは、index.php ファイルにあります。ビュー ファイルは、コンテンツのレンダリングに使用される HTML および PHP コードを含む PHP スクリプト ファイルです。
設定ファイルには任意の名前を付けることができます。構成ファイルは、構成を具体化する連想配列を返すことを主な目的とする PHP スクリプトです。
5. ディレクトリ
Yii は、さまざまな状況に応じて一連のデフォルトのディレクトリを想定しています。必要に応じて、各ディレクトリをカスタマイズできます。
WebRoot/protected: これはアプリケーションのベース ディレクトリであり、セキュリティに敏感なすべての PHP スクリプトとデータ ファイルが配置されます。 Yii には、このディレクトリを指すデフォルトのアプリケーションエイリアスがあります。このディレクトリとその中のファイルは、Web ユーザーによるアクセスから保護する必要があります。 CWebApplication::basePath を介してカスタマイズできます。
WebRoot/protected/runtime: このディレクトリには、アプリケーションの実行時に生成されるプライベート一時ファイルが含まれます。このディレクトリは、Web サーバー プロセスによって書き込み可能である必要があります。 CApplication::runtimePath を介してカスタマイズできます。
WebRoot/protected/extensions: このディレクトリには、すべてのサードパーティ拡張機能が配置されます。 CApplication::extensionPath を介してカスタマイズできます。
WebRoot/protected/modules: このディレクトリにはすべてのアプリケーション モジュールが配置され、各モジュールはサブディレクトリを使用します。
WebRoot/protected/controllers: このディレクトリには、すべてのコントローラー クラス ファイルが配置されます。 CWebApplication::controllerPath を介してカスタマイズできます。
WebRoot/protected/views: このディレクトリには、コントローラー ビュー、レイアウト ビュー、システム ビューを含むすべてのビュー ファイルが含まれています。 CWebApplication::viewPath を介してカスタマイズできます。
WebRoot/protected/views/ControllerID: このディレクトリには、単一のコントローラー クラスで使用されるビュー ファイルが配置されます。ここでのControllerIDはコントローラーのIDを指します。 CController::viewPath を介してカスタマイズできます。
WebRoot/protected/views/layouts: このディレクトリには、すべてのレイアウト ビュー ファイルが配置されます。 CWebApplication::layoutPath を介してカスタマイズできます。
WebRoot/protected/views/system: このディレクトリには、すべてのシステム ビュー ファイルが含まれています。システム ビュー ファイルは、例外とエラーを表示するために使用されるテンプレートです。 CWebApplication::systemViewPath を介してカスタマイズできます。
WebRoot/assets: このディレクトリにはパブリック リソース ファイルが配置されます。リソース ファイルは、Web ユーザーが公開してアクセスできるプライベート ファイルです。このディレクトリは、Web サーバー プロセスによって書き込み可能である必要があります。 CAssetManager::basePath を通じてカスタマイズできます。
WebRoot/themes: このディレクトリには、アプリケーションで使用されるさまざまなテーマが配置されます。各サブディレクトリはトピックであり、トピックの名前がディレクトリの名前になります。 CThemeManager::basePath を介してカスタマイズできます。
6. データベース
ほとんどの Web アプリケーションはデータベースによって駆動されます。テーブルと列に名前を付けるときは、次の命名規則を使用することをお勧めします。これらの仕様は Yii には必要ないことに注意してください。
㈠データベースのテーブル名とカラム名は小文字で付けられます。
㈡名前に含まれる単語はアンダースコアで区切る必要があります (例: product_order)。
㈢テーブル名は単数形でも複数形でも使用できます。ただし、両方を同時に使用しないでください。わかりやすくするために、単数形の名前を使用することをお勧めします。
㈣テーブル名には、tbl_ などの共通の接頭辞を使用できます。これは、アプリケーションで使用されるテーブルが、別のアプリケーションで使用されるテーブルと同じデータベースに共存する場合に特に便利です。これら 2 つのアプリケーションのテーブルは、異なるテーブル接頭辞を使用することで簡単に区別できます。
Ⅱ. フォームの使用
Yii でフォームを処理する場合、通常は次の手順が必要です:
1. 収集するデータフィールドを表すモデルクラスを作成します。
2. フォームの送信に応答するコントローラー アクションを作成します。
3. ビュースクリプトでコントローラーアクションに関連するフォームを作成します。
1. モデルを作成する
フォームに必要な HTML コードを記述する前に、まずエンド ユーザーから入力されるデータの種類と、このデータが準拠する必要があるルールを決定する必要があります。モデル クラスを使用して、この情報を記録できます。 「モデル」の章で定義されているように、モデルはユーザー入力を保存し、それらの入力を検証するための中心的な場所です。
ユーザーが入力したデータの用途に応じて、2種類のモデルを作成できます。ユーザー入力が収集され、使用されてから破棄される場合は、フォーム モデルを作成する必要があります。ユーザー入力が収集されてからデータベースに保存される場合は、アクティブ レコードを使用する必要があります。どちらのタイプのモデルも、フォームに必要な共通インターフェイスを定義する同じ基本クラス CModel を共有します。
1. モデルクラスを定義します
たとえば、フォームモデルを作成します:
class LoginForm extends CFormModel
{
public $username;
public $password;
public $rememberMe=false;
}
LoginForm では、$username、$password、$rememberMe の 3 つのプロパティが定義されています。これらは、ユーザーが入力したユーザー名とパスワードを保存するために使用され、ユーザーが自分のログインを覚えておきたい場合のオプションもあります。 $rememberMe のデフォルト値は false であるため、ログイン フォームに最初に表示されるとき、対応するオプションはオフになります。
通常のプロパティと区別するために、これらのメンバー変数をプロパティではなく属性と呼びます。属性は、主にユーザー入力またはデータベースからのデータを保存するために使用されるプロパティです。
2. 検証ルールを宣言する
ユーザーが入力を送信してモデルが設定されたら、使用する前にユーザーの入力が有効であることを確認する必要があります。これは、ユーザーの入力を一連のルールに照らして検証することによって実現されます。これらの検証ルールを rules() メソッドで指定すると、ルール設定の配列が返されます。
class LoginForm extends CFormModel
{
Public $username;
public $password;
public $rememberMe=false;
private $_identity;
public function rules()
{
Return array(
array('ユーザー名, パスワード', 'required'), // ユーザー名とパスワードは必須です
array('rememberMe', 'boolean'), // rememberMe はブール値である必要があります
array('password', 'authenticate'), // パスワードは次のとおりです認証される
);
}
public functionauthenticate($attribute,$params)
{
_identity=new UserIdentity($this->username,$this->password ; ) 返される各ルールは次のとおりである必要があります形式:
array('AttributeList', 'Validator', 'on'=>'ScenarioList', ... 追加オプション)
ここで:
AttributeList (属性リスト) は、このルールが渡す機能リストの文字列を渡す必要がありますvalidates は各機能名をカンマで区切ります。
Validator (バリデーター) は実行する検証のタイプを指定します。
このルールが適用されるシナリオのリストを指定します。対応するバリデーターのプロパティ値を初期化するために使用される名前と値のペア。
検証ルールで Validator を指定するには 3 つの方法があります:
まず、Validator は、上の例の認証と同様に、モデル クラスのメソッドの名前にすることができます。検証メソッドは次の構造を持つ必要があります:
public function validator name ($attribute, $params) { ... }
2 番目に、このルールが適用される場合、Validator はバリデータ クラスの名前にすることができます。実際の検証を実行するためにハンドラー クラスが作成されます。ルールの追加オプションは、インスタンスの属性値を初期化するために使用されます。 Validator クラスは CValidator から継承する必要があります。
第三に、Validator は、事前定義されたバリデーター クラスのエイリアスにすることができます。上の例では、必須の名前は CRequiredValidator のエイリアスであり、検証されるプロパティが空でないことを確認するために使用されます。事前定義されたバリデーター エイリアスの完全なリストは次のとおりです:
boolean: CBooleanValidator のエイリアス。属性に CBooleanValidator::trueValue または CBooleanValidator::falseValue 値があることを確認します。
captcha: CCaptchaValidator のエイリアス。特性値が CAPTCHA に表示される検証コードと等しいことを確認します。
compare: CCompareValidator のエイリアス。プロパティが別のプロパティまたは定数と等しいことを確認します。
email: CEmailValidator のエイリアス。属性が有効な電子メール アドレスであることを確認します。
デフォルト: CDefaultValueValidator のエイリアス。属性のデフォルト値を指定します。
exist: CExistValidator のエイリアス。指定されたテーブルの列で属性値が見つかることを保証します。
file: CFileValidator のエイリアス。属性にアップロードされたファイルの名前が含まれていることを確認してください。
filter: CFilterValidator のエイリアス。フィルターを通じてこのプロパティを変更します。
in: CRangeValidator のエイリアス。データが事前に指定された値の範囲内にあることを保証します。
length: CStringValidator のエイリアス。データの長さが指定された範囲内にあることを保証します。
match: C RegularExpressionValidator のエイリアス。データが正規表現と一致することを確認します。
数値: CNumberValidator のエイリアス。データが有効な数値であることを確認します。
必須: CRequiredValidator のエイリアス。属性が空でないことを確認します。
type: CTypeValidator のエイリアス。属性が指定されたデータ型であることを保証します。
unique: CUniqueValidator のエイリアス。データがデータ テーブル内の列間で一意であることを保証します。
url: CUrlValidator のエイリアス。データが有効な URL であることを確認します。
以下に、これらの定義済みバリデータのみを使用した例をいくつか示します:
// ユーザー名は必須です
array('username', 'required'),
// ユーザー名は 3 ～ 12 文字である必要があります
array('username' , 'length', 'min'=>3, 'max'=>12),
// 登録シナリオでは、パスワードのパスワードは、password2 と一致している必要があります。
array('password', 'compare', 'compareAttribute'=>'password2', 'on'=>'register'),
// ログイン シナリオでは、パスワードを検証する必要があります。
array('password', 'authenticate', 'on'=>'login'),
3. 安全な属性の割り当て
クラスのインスタンスが作成された後、通常、クラスのインスタンスに送信されたデータを入力する必要があります。エンドユーザーの特性。これは、次のような大規模な割り当てを行うことで簡単に実現できます:
$model=new LoginForm;
if(isset($_POST['LoginForm']))
$model->attributes=$_POST['LoginForm'] ;
最後の式は一括割り当てと呼ばれ、$_POST['LoginForm'] 内の各項目を対応するモデル属性にコピーします。これは、次の割り当てメソッドと同等です:
foreach($_POST['LoginForm'] as $name=>$value)
{
if($name は安全な機能です)
$model->$name=$ value ;
}
検出機能のセキュリティは非常に重要です。たとえば、テーブルの主キーが安全であると考えて公開すると、攻撃者がレコードの主キーを変更する機会を得る可能性があります。コンテンツに許可されていない情報を改ざんする。
機能は、対応するシナリオの検証ルールに含まれている場合、安全であるとみなされます。例:
array('ユーザー名, パスワード', 'required', 'on'=>'login, register'),
array('email', 'required', 'on'=>'register') ,
上記のように、ログインシナリオではユーザー名とパスワードの属性が必要です。登録シナリオでは、ユーザー名、パスワード、電子メールの属性が必要です。したがって、ログイン シナリオでブロック割り当てを実行すると、ユーザー名とパスワードのみがブロック割り当てされます。ログインの検証ルールに表示されるのはこれらだけであるためです。一方、シナリオが登録の場合は、3 つのプロパティすべてをブロックに割り当てることができます。
// ログイン シナリオの場合
$model=new User('login');
if(isset($_POST['User']))
$model->attributes=$_POST['User'];
// 登録シナリオでは
$model=new User('register');
if(isset($_POST['User']))
$model->attributes=$_POST['User'];
次に機能が安全かどうかを検出するためにこのような戦略を使用するのはなぜでしょうか?この背後にある理論的根拠は、「機能に有効性を検出できる 1 つ以上の検証ルールがすでにある場合、何を心配する必要があるでしょうか?」です。
検証ルールは、コード内で生成したデータ (タイムスタンプ、自動生成された主キーなど) ではなく、ユーザーが入力したデータをチェックするために使用されることに注意してください。したがって、エンドユーザー入力を受け入れない機能には検証ルールを追加しないでください。
ルールを何も指定しなくても、機能が安全であると宣言したい場合があります。たとえば、記事のコンテンツはユーザーからのあらゆる入力を受け入れることができます。特別な安全なルールを使用してこれを行うことができます:
array('content', 'safe')
プロパティを安全でないと宣言するための安全でないルールもあります:
array('permission', 'unsafe')
安全でないルールは次のとおりです。一般的には使用されず、以前に定義した安全性プロパティの例外です。
4. 検証をトリガーする
ユーザーが送信したデータがモデルに設定されたら、CModel::validate() を呼び出してデータ検証プロセスをトリガーできます。このメソッドは、検証が成功したかどうかを示す値を返します。 CActiveRecord モデルの場合、CActiveRecord::save() メソッドを呼び出したときに検証を自動的にトリガーすることもできます。
シナリオ属性を設定することでシナリオのプロパティを設定し、対応するシナリオの検証ルールが適用されるようにすることができます。
検証はシナリオに基づいて実行されます。 scenario 属性は、モデルが現在使用されているシナリオと、現在使用されている検証ルールのセットを指定します。たとえば、ログイン シナリオでは、ユーザー モデルでのユーザー名とパスワードの入力のみを検証する必要がありますが、登録シナリオでは、電子メール、アドレスなどの追加の入力を検証する必要があります。次の例は、登録シナリオで検証を実行する方法を示しています:
// 登録シナリオで User モデルを作成します。以下と同等:
// $model=new User;
// $model->scenario='register';
$model=new User('register') // モデル クラスにパラメータを追加します。トリガーされるシナリオ
// モデルに入力値を入力します
$model->attributes=$_POST['User'];
// 検証を実行します
if($model->validate()) // 入力が有効な場合
シナリオは、次の on オプションで指定できます。ルール。 on オプションが設定されていない場合、このルールはすべてのシナリオに適用されます。例:
public function rules()
{
return array(
array('ユーザー名, パスワード', 'required'),
array('password_repeat', 'required', 'on'=>'register') ,
array('password', 'compare', 'on'=>'register'),
);
}
最初のルールはすべてのシナリオに適用され、2 番目のルールは登録シナリオにのみ適用されます。
5. 検証エラーの抽出
検証が完了すると、発生する可能性のあるエラーはモデル オブジェクトに保存されます。これらのエラー メッセージは、CModel::getErrors() および CModel::getError() を呼び出すことで抽出できます。これら 2 つのメソッドの違いは、最初のメソッドはすべてのモデル プロパティのエラー情報を返すのに対し、2 番目のメソッドは最初のメソッドのエラー情報のみを返すことです。
6. 機能ラベル
フォームをデザインするときは、通常、フォームフィールドごとにラベルを表示する必要があります。ラベルは、このフォーム フィールドにどのような情報を入力する必要があるかをユーザーに示します。ビューでラベルをハードコードすることもできますが、対応するモデルで（ラベルを）指定すると、より柔軟で便利です。
デフォルトでは、CModel は単に属性の名前をラベルとして返します。これは、attributeLabels() メソッドをオーバーライドすることでカスタマイズできます。次のセクションで説明するように、モデル内でタグを指定すると、より強力なフォームをより速く作成できるようになります。
2. アクションを作成する
モデルを用意したら、このモデルを操作するためのロジックの作成を開始できます。このロジックをコントローラーのアクションに組み込みます。ログイン フォームの例の場合、対応するコードは次のとおりです:
public function actionLogin()
{
$model=new LoginForm;
if(isset($_POST['LoginForm']))
{
データ
$model->属性=$_POST['ログインフォーム'];
use using ‐ ‐ ‐ ‐ ‐ ‐ ‐ using using using using data
through out through ''s' out's ‐ ‐ to ‐‐‐‐‐‐‐‐ および $this ->redirect(Yii::app()->user->returnUrl); //以前に認証が必要だったページ URL にリダイレクトします
}
//ログインフォームを表示します
$this->render (' login',array('model'=>$model));
}
上で示したように、リクエストが POST リクエスト (ログイン フォームが送信されることを意味する) の場合は、まず LoginForm モデルのサンプルを作成します。 $model に送信されたデータ $_POST['LoginForm'] を設定し、この入力を検証し、検証が成功した場合は、以前に認証を必要としたページにユーザーのブラウザをリダイレクトします。検証が失敗した場合、またはこのアクションに初めてアクセスした場合、ログイン ビューが表示されます。このビューの内容については次のセクションで説明します。
ヒント: ログインアクションでは、Yii::app()->user->returnUrl を使用して、以前に認証を必要としたページの URL を取得します。 コンポーネント Yii::app()->user は、ユーザー セッション情報 (ユーザー名、ステータスなど) を表す CWebUser (またはそのサブクラス) です。
ログイン アクションに表示される次の PHP ステートメントに特に注意してください:
$model->attributes=$_POST['LoginForm'];
安全な属性の割り当てで述べたように、このコード行はユーザーを使用します。送信されたデータがモデルに入力されます。属性プロパティは CModel によって定義され、名前と値のペアの配列を受け取り、各値を対応するモデル属性に割り当てます。したがって、$_POST['LoginForm'] が次のような配列を提供する場合、上記のコードは次の長い段落と同等になります (必要な属性がすべて配列内に存在すると仮定します):
$model->username =$_POST[ 'LoginForm']['username'];
$model->password=$_POST['LoginForm']['password'];
$model->rememberMe=$_POST['LoginForm'] ['rememberMe' ];
注: $_POST['LoginForm'] が文字列ではなく配列を渡すようにするには、フォーム フィールドに名前を付けるときに規則に従う必要があります。具体的には、モデル クラス C のフィーチャ a に対応するフォーム フィールドに C[a] という名前を付けます。たとえば、LoginForm[username] を使用して、username 属性に対応するフォーム フィールドに名前を付けることができます。
あとは、必要な入力を含む HTML フォームを含むログイン ビューを作成するだけです。
三、创建表单
编写 login 视图是很简单的，我们以一个 form 标记开始，它的 action 属性应该是前面讲述的 login 动作的URL。然后我们需要为 LoginForm 类中声明的属性插入标签和表单域。最后，我们插入一个可由用户点击提交此表单的提交按钮。所有这些都可以用纯HTML代码完成。
Yii 提供了几个助手（helper）类简化视图编写。例如，要创建一个文本输入域，我们可以调用 CHtml::textField()；要创建一个下拉列表，则调用 CHtml::dropDownList()。
例如， 如下代码将生成一个文本输入域，它可以在用户修改了其值时触发表单提交动作。
CHtml::textField($name,$value,array('submit'=>''));
下面，我们使用 CHtml 创建一个登录表单。我们假设变量 $model 是 LoginForm 的实例。
上述代码生成了一个更加动态的表单，例如， CHtml::activeLabel() 生成一个与指定模型的特性相关的标签。如果此特性有一个输入错误，此标签的CSS class 将变为 error，通过 CSS 样式改变了标签的外观。相似的， CHtml::activeTextField() 为指定模型的特性生成一个文本输入域，并会在错误发生时改变它的 CSS class。
我们还可以使用一个新的小物件 CActiveForm 以简化表单创建。这个小物件可同时提供客户端及服务器端无缝的、一致的验证。使用 CActiveForm, 上面的代码可重写为：
beginWidget('CActiveForm'); ?>
errorSummary($model); ?>
label($model,'username'); ?>
textField($model,'username') ?>
label($model,'password'); ?>
passwordField($model,'password') ?>
checkBox($model,'rememberMe'); ?>
label($model,'rememberMe'); ?>
endWidget(); ?>
4. フォーム入力を収集する
バッチ モードを通じてユーザー入力を収集したい場合があります。つまり、ユーザーは複数のモデル インスタンスの情報を入力し、それらをすべて一度に送信できます。これらの入力は通常 HTML テーブルとして表示されるため、この入力を表形式入力と呼びます。
テーブル入力を使用するには、データを挿入するか更新するかに応じて、まずモデル インスタンスの配列を作成または設定する必要があります。次に、ユーザーが入力したデータを $_POST 変数から抽出し、各モデルに割り当てます。単一モデル入力とのわずかな違いは、入力データを抽出するために $_POST['ModelClass'] を使用する代わりに $_POST['ModelClass'][$i] を使用する必要があることです。
public function actionBatchUpdate()
{
// 各項目が 'Item' クラスのインスタンスであると仮定して、
// 更新する項目をバッチ モードで抽出します
$items=$this->getItemsToUpdate() ;
if(isset($_POST['Item']))
{
$valid=true;
foreach($items as $i=>$item)
{
if(isset($_POST['Item' ][ $i]))
$item->attributes=$_POST['Item'] $items));
}
; このアクションの準備ができたら、batchUpdate ビューの作業を続ける必要があります。の入力項目を表示しますHTML テーブル。
| Name | 価格 | 個数 | 説明 | |
|---|---|---|---|---|