symfony データ検証メソッド分析例、symfony サンプル分析_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 10:08:56731ブラウズ
symfony データ検証方法の分析例、symfony の分析例
この記事の例では、Symfony データ検証方法について説明します。参考のためにみんなで共有してください。具体的な分析は次のとおりです:
検証は、Web アプリケーションの一般的なタスクです。フォームに入力されたデータは検証される必要があります。データは、データベースに書き込まれる前、または Web サービスに渡されるときにも検証する必要があります。
Symfony2 には Validator コンポーネントが装備されており、検証作業をシンプルかつ理解しやすくします。このコンポーネントは、JSR303 Bean 検証仕様に基づいています。 PHP で使用するための Java 仕様。
基本的な検証
検証を理解する最良の方法は、検証がどのように実行されるかを確認することです。まず、アプリケーションのどこかで使用される PHP オブジェクトを作成したと仮定します。
名前空間 AcmeBlogBundleEntity;
クラス作成者
{
パブリック $name;
}
ここまでは、アプリケーション内で何らかの目的を果たす単なる通常のクラスです。検証の目的は、オブジェクトのデータが合法かどうかを判断することです。この目的のために、ルールまたは制約のリストに従ってオブジェクトを構成し、そのデータを合法にする必要があります。これらのルールは、さまざまな形式 (YAML、XML、クラス宣言、PHP など) で記述できます。たとえば、属性 $name を空にすることはできないので、次のルールを追加します:
YAML形式:
AcmeBlogBundleEntity作成者:
プロパティ:
名前:
- NotBlank: ~
クラス宣言の形式:
SymfonyComponentValidatorConstraints をアサートとして使用します;
クラス作成者
{
/**
* @AssertNotBlank()
*/
パブリック $name;
}
XML形式:
xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping http://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">
<クラス名="AcmeBlogBundleEntityAuthor">
<プロパティ名="名前">
＆lt;制約名= "notblank" /＆gt;
PHP コード形式:
SymfonyComponentValidatorMappingClassMetadataを使用します;
SymfonyComponentValidatorConstraintsNotBlank を使用します;
クラス作成者
{
パブリック $name;
パブリック静的関数loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('name', new NotBlank());
}
}
保護されたプライベート属性とゲッター メソッドも検証できます。
バリデーターサービスを使用する:
次に、バリデーターサービスの validate メソッドを使用して、Author オブジェクトを実際に検証します。バリデーターの仕事は単純です。クラスの制約ルールを読み取り、オブジェクトのデータがこれらのルール制約に準拠しているかどうかを検証します。検証が失敗した場合は、エラー配列が返されます。次に、コントローラーで実行します:
AcmeBlogBundleEntityAuthor を使用します;
//...
パブリック関数indexAction()
{
$author = 新しい著者();
//... $auother オブジェクトをどうするか
$validator = $this->get('validator');
$errors = $validator->validate($author);
if(count($errors) >0){
新しい応答を返します(print_r($errors, true));
}その他{
新しい応答を返します('著者は有効です! はい!');
}
}
$name 属性が空の場合、次のエラー メッセージが表示されます:
AcmeBlogBundle作者名:
この値は空白であってはなりません
$name 属性の値を挿入すると、成功を示すメッセージが表示されます。
ほとんどの場合、バリデーターサービスと直接通信する必要はなく、印刷エラーについて心配する必要もまったくありません。
ほとんどの場合、送信されたフォーム データを処理するときに間接的に検証を使用します。
エラー メッセージのコレクションをテンプレートに渡すこともできます:
Return $this->render('AcmeBlogBundle:Author:validate.html.twig',array(
) 'エラー' => $errors,
));
}その他{
//...
}
テンプレートでは、必要に応じて正確にエラー リストを出力できます。
小枝形式:
作成者には次のエラーがあります
- {{ エラー.メッセージ }}
{% エラー中のエラー %}
{% 終了用 %}
チェックサムフォーム
バリデーター サービスを使用すると、いつでもオブジェクトを検証できます。 実際、フォームを処理するときに間接的にバリデーターを使用することがよくあります。 Symfony のフォーム ライブラリは、データが送信されてバインドされた後、間接的にバリデーター サービスを使用して、基礎となるオブジェクトを検証します。オブジェクト制約違反情報は FieldError オブジェクトに変換され、フォームに簡単に表示できます。コントローラーでの従来のフォーム送信プロセスは次のとおりです:
AcmeBlogBundleFormAuthorType を使用します;
AcmeComponentHttpFoundationRequest を使用します;
//...
パブリック関数 updateAction(Request $request)
{
$author = 新しい AcmeBlogBundleEntityAuthor();
$form = $this->createForm(new AuthorType(),$author);
if($request->getMethod() =='POST'){
$form->bindRequest($request);
If($form->isvalid()){
// $author
に対していくつかの操作を実行します
return $this->redirect($this->generateUrl('...'));
}
}
return $this->render('BlogBundle:Author:form.html.twig',array(
)
'フォーム' => $form->createView(),
));
}
構成:
Symfony2 のバリデーターはデフォルトで利用可能です。ただし、life メソッドを使用して制約を指定する場合は、宣言関数を明示的に有効にする必要があります:
YAML形式:
フレームワーク:
検証: {enable_annotations: true }
XML形式:
<フレームワーク:構成>
PHP コード形式:
$contianer->loadFromExtension('framework',array('validation'=> array(
) 'enable_annotations'=>true,
)));
制約ルール
Validator は、制約ルールに従ってオブジェクトを検証するように設計されています。オブジェクトを検証するには、検証対象のクラスに 1 つ以上の制約をマップし、それを検証サービスに渡すだけです。
本質的に、制約は決定ステートメントを生成する単純な PHP オブジェクトです。 現実の世界では、制約は「ケーキを焼くことができない」などのルール制約になる可能性があります。 Symfony2 では、制約はすべて同じです。制約は特定の条件が true であるかどうかを決定します。値を指定すると、その値が制約ルールに従っているかどうかが制約によってわかります。
Symfony2 でサポートされる制約ルール
まず、基本的な制約ルールです。オブジェクトのプロパティの値やメソッドの戻り値など、非常に基本的なものを決定するために使用します。
NotBlank、Blank、NotNull、Null、True、False、Type
文字列制約: Email、MinLength、MaxLength、Url、Regex、Ip など
数値制約: 最大、最小
日付の制約: 日付、日時、時刻
コレクションの制約: 選択、コレクション、UniqueEntity、言語、ロケール、国など。
ファイルの制約: ファイル、画像
その他の制約: コールバック、すべて、有効
独自のカスタム制約を作成することもできます。
制約構成:
NotBlank などの一部の制約は非常に単純ですが、Choice 制約などの他の制約には設定が必要な構成項目が多数あります。 Author クラスに別の属性があると仮定すると、gener を「男性」または「女性」に設定できます:
YAML形式:
AcmeBlogBundleEntity作成者:
プロパティ:
ジェネレーター:
- 選択肢: { 選択肢: [男性、女性]、メッセージ: 有効な性別を選択してください。 クラス宣言の形式:
クラス作成者 {
/**
* @AssertChoice(
* 選択肢 = {"男性","女性"},
* メッセージ = 「有効な性別を選択してください。」
*)
*/
公開 $gender;
}
xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping http://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">
<クラス名="AcmeBlogBundleEntityAuthor"> <プロパティ名="性別">
で
& Lt; オプション名 = "メッセージ" & gt; 値の性別を選択します。
PHP コード形式:
コードをコピーします
SymfonyComponentValidatorMappingClassMetadata を使用します;
SymfonyComponentValidatorConstraintsNotBlank を使用します;
クラス作成者
{
公開 $gender;
パブリック静的関数loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('gender', new Choice(array(
)
'選択' => array('男性', '女性'),
'メッセージ' => '有効な性別を選択してください。',
)));
}
}
制約オプションは通常、配列を介して渡されます。一部の制約では、値を渡すこともできます。 「default」は配列ではオプションです。選択制約を使用する場合、選択肢オプションはこの方法で指定できます。
YAML形式:
AcmeBlogBundleEntity作成者:
プロパティ:
性別:
- 選択肢: [男性、女性]
クラス宣言の形式:
SymfonyComponentValidatorConstraints をアサートとして使用します;
クラス作成者
{
/**
* @AssertChoice({"男性", "女性"})
*/
保護された $gender;
}
XML形式:
xsi:schemaLocation="http://symfony.com/schema/dic/constraint-mapping http://symfony.com/schema/dic/constraint-mapping/constraint-mapping-1.0.xsd">
<クラス名="AcmeBlogBundleEntityAuthor">
<プロパティ名="性別">
<制約名="選択">
PHP形式:
コードをコピーします
クラス作成者
{ 保護された $gender;
パブリック静的関数loadValidatorMetadata(ClassMetadata $metadata)
{
}
}
制約はクラスプロパティまたはパブリックゲッターメソッドに適用できます。属性制約は最も一般的に使用され、最も単純ですが、パブリック ゲッター メソッド制約を使用すると、複雑な制約ルールを指定できます。
属性制約:
検証クラスのプロパティは、最も一般的な検証手法の 1 つです。 Symfony2 を使用すると、プライベート、保護された、またはパブリックのプロパティを検証できます。次のコードは、Author オブジェクトの $firstName プロパティを少なくとも 3 文字を持つように構成する方法を示しています。 YAML形式:
コードをコピーします
AcmeBlogBundleEntity作成者:
プロパティ:
名:
- NotBlank: ~
- MinLength: 3
クラス宣言の形式:
SymfonyComponentValidatorConstraints をアサートとして使用します;
クラス作成者
{
/**
* @AssertNotBlank()
* @AssertMinLength(3)
*/
プライベート $firstName;
}
XML形式:
<クラス名="AcmeBlogBundleEntityAuthor">
<プロパティ名="firstName">
<制約名="NotBlank" />
<制約名="MinLength">3
PHP コード形式:
SymfonyComponentValidatorMappingClassMetadata を使用します;
SymfonyComponentValidatorConstraintsNotBlank を使用します;
SymfonyComponentValidatorConstraintsMinLength を使用します;
クラス作成者
{
プライベート $firstName;
パブリック静的関数loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('firstName', new NotBlank());
$metadata->addPropertyConstraint('firstName', new MinLength(3));
}
}
ゲッターズ
制約はメソッドの戻り値にも適用できます。 Symfony2 では、「get」または「is」で始まるパブリック メソッドに制約を追加できます。この手法の利点は、オブジェクトを動的に検証できることです。たとえば、パスワード フィールドがユーザーの名と一致しないことを確認したいとします (セキュリティ上の理由から)。これを行うには、idPasswordLegal メソッドを作成し、このメソッドが true を返す必要があると判断します:
YAML形式:
AcmeBlogBundleEntity作成者:
ゲッター:
パスワード法的事項:
- "True": { メッセージ: "パスワードはあなたの名と一致しません" }
クラス宣言の形式:
SymfonyComponentValidatorConstraints をアサートとして使用します;
クラス作成者
{
/**
* @AssertTrue(メッセージ = "パスワードはあなたの名と一致しません")
*/
パブリック関数 isPasswordLegal()
{
// true または false を返します
}
}
XML形式:
<クラス名="AcmeBlogBundleEntityAuthor">
<制約名="True">
SymfonyComponentValidatorMappingClassMetadata を使用します;
SymfonyComponentValidatorConstraintsTrue を使用します;
クラス作成者
{
パブリック静的関数loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addGetterConstraint('passwordLegal', new True(array(
)
'message' => 'パスワードはあなたの名と一致しません',
)));
}
}
次に、isPasswordLegal() メソッドを作成し、必要なロジックを含めます。
{
Return ($this->名 != $this->パスワード);
}
目の肥えた人は、ゲッターのプレフィックス (「get」または「is」) がマッピング時に無視されることに気づくかもしれません。これにより、検証ルールを変更せずに、制約を同じ名前のプロパティに移動したり、その逆に移動したりすることができます。
カテゴリー:
いくつかの制約は検証対象のクラス全体に適用されます。たとえば、コールバック制約は、クラス自体に適用できる一般的な制約です。クラスが検証されると、制約によって記述されたメソッドが単純に実行されるため、それぞれがよりパーソナライズされた検証を提供できます。
検証グループ化
これまでのところ、クラスに制約を追加し、クラスが定義されたすべての制約ルールに合格したかどうかを確認することができました。場合によっては、クラスのルールの一部を使用してオブジェクトを検証するだけで済みます。これを行うには、各制約を 1 つ以上の検証グループに編成し、アプリケーションで検証グループの 1 つを使用します。たとえば、ユーザーが登録するときと連絡先情報を更新するときに使用される User クラスがあるとします。
YAML形式:
AcmeBlogBundleEntityUser:
プロパティ:
メール:
- メール: { グループ: [登録] }
パスワード:
- NotBlank: { グループ: [登録] }
- MinLength: { 制限: 7、グループ: [登録] }
市:
- MinLength: 2
クラス宣言の形式:
名前空間 AcmeBlogBundleEntity;
SymfonyComponentSecurityCoreUserUserInterfaceを使用します;
SymfonyComponentValidatorConstraints をアサートとして使用します;
ユーザーが UserInterface を実装するクラス
{
/**
* @AssertEmail(groups={"登録"})
*/
プライベート $email;
/**
* @AssertNotBlank(グループ={"登録"})
* @AssertMinLength(limit=7, groups={"登録"})
*/
プライベート $パスワード;
/**
* @AssertMinLength(2)
*/
プライベート $city;
}
XML形式:
<クラス名="AcmeBlogBundleEntityUser">
<プロパティ名="電子メール">
<制約名="電子メール">
<オプション名="グループ">
<プロパティ名="パスワード">
<制約名="NotBlank">
<オプション名="グループ">
<制約名="MinLength">
<オプション名="制限">7
<オプション名="グループ">
<プロパティ名="都市">
<制約名="MinLength">7
PHP代格格式：
名前空間 AcmeBlogBundleEntity;
SymfonyComponentValidatorMappingClassMetadataを使用します;
SymfonyComponentValidatorConstraintsEmail を使用します;
SymfonyComponentValidatorConstraintsNotBlank を使用します;
SymfonyComponentValidatorConstraintsMinLength を使用します;
クラスユーザー
{
パブリック静的関数loadValidatorMetadata(ClassMetadata $metadata)
{
$metadata->addPropertyConstraint('email', new Email(array(
)
'グループ' => array('登録')
)));
$metadata->addPropertyConstraint('パスワード', new NotBlank(array(
)
'グループ' => array('登録')
)));
$metadata->addPropertyConstraint('パスワード', new MinLength(array(
)
'制限' => 7、
'グループ' => array('登録')
)));
$metadata->addPropertyConstraint('city', new MinLength(3));
}
}
这里我们配置了两个校验组：
デフォルトの承認グループ: どのグループにも割り当てられていないすべての制限承認が含まれます
登録: メールアドレスとパスワードの文字列のみが含まれる学校验规则
告発validator は指定された校验組を使用し、1 つまたは複数の組の代表作は validate() メソッドの 2 番目のパラメータです。
値と配列の検証
これまで、オブジェクト全体を検証する方法について見てきました。ただし、文字列が正当な電子メール アドレスであるかどうかを確認するなど、単一の値を確認したい場合もあります。これは非常に簡単で、次のようにコントローラー クラスで実行されます:
SymfonyComponentValidatorConstraintsEmail を使用します;
パブリック関数 addEmailAction($email)
{
$emailConstraint = 新しいメール();
// すべての検証オプションは次のように設定できます
$emailConstraint->message = '無効なメール アドレス';
// バリデーターを使用して値を検証します
$errorList = $this->get('validator')->validateValue($email, $emailConstraint);
if (count($errorList) == 0) {
// これは正当なメール アドレスです。何ができるでしょうか
} その他 {
// これは不正なメールアドレスです
$errorMessage = $errorList[0]->getMessage()
// エラー処理を実行します
}
// ...
}
バリデーターの validateValue メソッドを呼び出すことで、生の値と使用する検証オブジェクトを渡すことができます。このメソッドは、エラー メッセージの配列の役割のみを担う ConstraintViolationList オブジェクトを返します。コレクション内の各エラーは ConstraintViolation オブジェクトであり、エラー情報はオブジェクトの getMessage メソッドを使用して取得できます。
概要:
Symfony2 のバリデーターは、あらゆるオブジェクト データの有効性を確認するために使用できる強力なツールです。その威力は、オブジェクトのプロパティとゲッター メソッドに適用できる制約ルールから得られます。実際、フォームを使用する場合、ほとんどの場合、検証フレームワークは間接的に使用され、任意のオブジェクトを検証するためにどこにでも適用できることに注意してください。
この記事で説明した内容が皆さんの Symfony フレームワーク プログラミングに役立つことを願っています。