Examples of form usage in Yii-PHP Tutorial-php.cn

This article mainly introduces the usage of forms in Yii. It combines a more detailed analysis with examples and summarizes various commonly used operating techniques for forms in Yii. It has certain reference value. Friends in need can refer to it

The examples in this article describe the usage of forms in Yii. Share it with everyone for your reference, the details are as follows:

When processing forms in Yii, the following steps are usually required:

1. Create a model class to represent the data fields to be collected.
2. Create a controller action to respond to form submission.
3. Create a form related to the controller action in the view script.

1. Create a model

Before writing the HTML code required for the form, we should first determine the type of data input from the end user, and how these data should conform to What kind of rules. Model classes can be used to record this information. As defined in the Models chapter, models are the central location for storing user input and validating those inputs.

Depending on how the data entered by the user is used, we can create two types of models. If user input is collected, used and then discarded, we should create a form model;

If user input is collected and then saved to the database, we should use an Active Record. Both types of models share the same base class CModel, which defines the common interface required by the form.

1. Define the model class

For example, create a form model:

class LoginForm extends CFormModel { public $username; public $password; public $rememberMe=false; }

Copy after login

LoginForm Three attributes are defined in: $username, $password and $rememberMe. They are used to save the username and password entered by the user, and also have the option if the user wants to remember his login. Since $rememberMe has a default value of false, the corresponding option will be unchecked when initially displayed in the login form.

We call these member variables attributes (attributes) rather than properties (properties) to distinguish them from ordinary properties (properties). An attribute is a property primarily used to store data from user input or database.

2. Declaration of validation rules

Once the user submits his input and the model is populated, we need to ensure that the user's input is valid before use. This is achieved by validating the user's input against a series of rules. We specify these validation rules in the rules() method, which should return an array of rule configurations.

class LoginForm extends CFormModel { public $username; public $password; public $rememberMe=false; private $_identity; public function rules() { return array( array('username, password', 'required'), //username 和 password 为必填项 array('rememberMe', 'boolean'), //rememberMe 应该是一个布尔值 array('password', 'authenticate'), //password 应被验证（authenticated） ); } public function authenticate($attribute,$params) { $this->_identity=new UserIdentity($this->username,$this->password); if(!$this->_identity->authenticate()) $this->addError('password','错误的用户名或密码。'); } }

Copy after login

rules() Each rule returned must be in the following format:

array('AttributeList', 'Validator', 'on'=>'ScenarioList', ...附加选项)

Copy after login

Where:

AttributeList(Attribute List) is a list string of attributes that need to be verified by this rule, with each attribute name separated by commas;
Validator (validator) specifies the type of validation to be performed; the
on parameter is optional, and it specifies this List of scenarios to which the rule should be applied;

Additional options are an array of name-value pairs used to initialize the attribute values of the corresponding validator.

There are three ways to specify Validator in validation rules:

First, Validator can be the name of a method in the model class, like authenticate in the example above. The validation method must be of the following structure:

public function 验证器名称($attribute,$params) { ... }

Copy after login

Second, Validator can be the name of a validator class. When this rule is applied, an instance of the validator class will be created to perform the actual validation. Additional options in the rules are used to initialize the instance's attribute values. Validator classes must inherit from CValidator.

Third, Validator can be an alias of a predefined validator class. In the example above, the required name is an alias for CRequiredValidator, which is used to ensure that the property value being validated is not null. Here is the complete list of predefined validator aliases:

boolean: Alias for CBooleanValidator, ensuring that the attribute has a CBooleanValidator::trueva lue or CBooleanValidator::falseva lue value.
captcha: Alias for CCaptchaValidator, ensuring that the attribute value is equal to the verification code displayed in the CAPTCHA.
compare: Alias for CCompareva lidator, ensuring that a property is equal to another property or constant.
email: Alias for CEmailValidator, ensuring the attribute is a valid email address.
default: Alias of CDefaultValueva lidator, specifying the default value of the attribute.
exist: Alias for CExistValidator, ensuring that attribute values can be found in columns of the specified table.
file: Alias for CFileva lidator, make sure the attribute contains the name of an uploaded file.
filter: Alias of CFilterValidator, changes this property through a filter.
in: Alias for CRangeva lidator, ensuring data is within a range of a pre-specified value.
length: Alias of CStringValidator, ensuring that the length of data is within a specified range.
match: Alias of CRegularExpressionValidator, ensuring that the data can match a regular expression.
numerical: Alias of CNumberValidator, ensuring that the data is a valid number.
required: Alias for CRequiredValidator, ensuring the attribute is not empty.
type: Alias for CTypeva lidator, ensuring that the attribute is of the specified data type.
unique: Alias of CUniqueva lidator, ensuring that data is unique among columns in the data table.
url: Alias of CUrlValidator, ensuring the data is a valid URL.

下面我们列出了几个只用这些预定义验证器的示例：

// 用户名为必填项 array('username', 'required'), // 用户名必须在 3 到 12 个字符之间 array('username', 'length', 'min'=>3, 'max'=>12), // 在注册场景中，密码password必须和password2一致。 array('password', 'compare', 'compareAttribute'=>'password2', 'on'=>'register'), // 在登录场景中，密码必须接受验证。 array('password', 'authenticate', 'on'=>'login'),

Copy after login

3、安全的特性赋值

在一个类的实例被创建后，我们通常需要用最终用户提交的数据填充它的特性。这可以通过如下块赋值（massive assignment）方式轻松实现：

$model=new LoginForm; if(isset($_POST['LoginForm'])) $model->attributes=$_POST['LoginForm'];

Copy after login

最后的表达式被称作块赋值（massive assignment），它将 $_POST['LoginForm'] 中的每一项复制到相应的模型特性中。这相当于如下赋值方法：

foreach($_POST['LoginForm'] as $name=>$value) { if($name 是一个安全的特性) $model->$name=$value; }

Copy after login

检测特性的安全非常重要，例如，如果我们以为一个表的主键是安全的而暴露了它，那么攻击者可能就获得了一个修改记录的主键的机会，从而篡改未授权给他的内容。

特性如果出现在相应场景的一个验证规则中，即被认为是安全的。例如：

array('username, password', 'required', 'on'=>'login, register'), array('email', 'required', 'on'=>'register'),

Copy after login

如上所示， username 和 password 特性在 login 场景中是必填项。而 username, password 和 email特性在 register 场景中是必填项。于是，如果我们在 login 场景中执行块赋值，就只有 username 和 password会被块赋值。因为只有它们出现在 login 的验证规则中。另一方面，如果场景是 register ，这三个特性就都可以被块赋值。

// 在登录场景中 $model=new User('login'); if(isset($_POST['User'])) $model->attributes=$_POST['User']; // 在注册场景中 $model=new User('register'); if(isset($_POST['User'])) $model->attributes=$_POST['User'];

Copy after login

那么为什么我们使用这样一种策略来检测特性是否安全呢？背后的基本原理就是：如果一个特性已经有了一个或多个可检测有效性的验证规则，那我们还担心什么呢？

请记住，验证规则是用于检查用户输入的数据，而不是检查我们在代码中生成的数据（例如时间戳，自动产生的主键）。因此，不要为那些不接受最终用户输入的特性添加验证规则。

有时候，我们想声明一个特性是安全的，即使我们没有为它指定任何规则。例如，一篇文章的内容可以接受用户的任何输入。我们可以使用特殊的 safe 规则实现此目的：

array('content', 'safe')

Copy after login

还有一个用于声明一个属性为不安全的 unsafe 规则：

array('permission', 'unsafe')

Copy after login

unsafe 规则并不常用，它是我们之前定义的安全特性的一个例外。

4、触发验证

一旦模型被用户提交的数据填充，我们就可以调用 CModel::validate() 触发数据验证进程。此方法返回一个指示验证是否成功的值。对CActiveRecord 模型来说，验证也可以在我们调用其 CActiveRecord::save() 方法时自动触发。

我们可以通过设置scenario属性来设置场景属性，这样，相应场景的验证规则就会被应用。

验证是基于场景执行的。 scenario属性指定了模型当前用于的场景和当前使用的验证规则集。例如，在 login 场景中，我们只想验证用户模型中的username 和 password 输入；而在 register 场景中，我们需要验证更多的输入，例如 email, address,等。下面的例子演示了如何在 register 场景中执行验证：

// 在注册场景中创建一个 User 模型。等价于： // $model=new User; // $model->scenario='register'; $model=new User('register'); //给模型类添加参数，该参数就是要触发的验证场景 // 将输入的值填充到模型 $model->attributes=$_POST['User']; // 执行验证 if($model->validate()) // 如果输入有效 ... else ...

Copy after login

规则关联的场景可以通过规则中的 on 选项指定。如果 on 选项未设置，则此规则会应用于所有场景。例如：

public function rules() { return array( array('username, password', 'required'), array('password_repeat', 'required', 'on'=>'register'), array('password', 'compare', 'on'=>'register'), ); }

Copy after login

第一个规则将应用于所有场景，而第二个将只会应用于 register 场景。

5、提取验证错误

验证完成后，任何可能产生的错误将被存储在模型对象中。我们可以通过调用 CModel::getErrors()和CModel::getError() 提取这些错误信息。这两个方法的不同点在于第一个方法将返回所有模型特性的错误信息，而第二个将只返回第一个错误信息。

6、特性标签

当设计表单时，我们通常需要为每个表单域显示一个标签。标签告诉用户他应该在此表单域中填写什么样的信息。虽然我们可以在视图中硬编码一个标签，但如果我们在相应的模型中指定（标签），则会更加灵活方便。

默认情况下 CModel 将简单的返回特性的名字作为其标签。这可以通过覆盖 attributeLabels() 方法自定义。正如在接下来的小节中我们将看到的，在模型中指定标签会使我们能够更快的创建出更强大的表单。

二、创建动作

有了模型，我们就可以开始编写用于操作此模型的逻辑了。我们将此逻辑放在一个控制器的动作中。对登录表单的例子来讲，相应的代码就是：

public function actionLogin() { $model=new LoginForm; if(isset($_POST['LoginForm'])) { // 收集用户输入的数据 $model->attributes=$_POST['LoginForm']; // 验证用户输入，并在判断输入正确后重定向到前一页 if($model->validate()) $this->redirect(Yii::app()->user->returnUrl); //重定向到之前需要身份验证的页面URL } // 显示登录表单 $this->render('login',array('model'=>$model)); }

Copy after login

如上所示，我们首先创建了一个 LoginForm 模型示例；如果请求是一个 POST 请求（意味着这个登录表单被提交了），我们则使用提交的数据$_POST['LoginForm'] 填充 $model；然后我们验证此输入，如果验证成功，重定向用户浏览器到之前需要身份验证的页面。如果验证失败，或者此动作被初次访问，我们则渲染 login视图，此视图的内容将在后续章节中讲解。

提示: 在 login 动作中，我们使用Yii::app()->user->returnUrl 获取之前需要身份验证的页面URL。组件Yii::app()->user 是一种 CWebUser (或其子类) ，它表示用户会话信息（例如用户名，状态）。

让我们特别留意一下 login 动作中出现的下面的 PHP 语句：

$model->attributes=$_POST['LoginForm'];

Copy after login

正如我们在安全的特性赋值中所讲的，这行代码使用用户提交的数据填充模型。 attributes 属性由 CModel定义，它接受一个名值对数组并将其中的每个值赋给相应的模型特性。因此如果 $_POST['LoginForm']给了我们这样的一个数组，上面的那段代码也就等同于下面冗长的这段 (假设数组中存在所有所需的特性):

$model->username=$_POST['LoginForm']['username']; $model->password=$_POST['LoginForm']['password']; $model->rememberMe=$_POST['LoginForm']['rememberMe'];

Copy after login

注意: 为了使 $_POST['LoginForm'] 传递给我们的是一个数组而不是字符串，我们需要在命名表单域时遵守一个规范。具体的，对应于模型类 C 中的特性 a 的表单域，我们将其命名为 C[a] 。例如，我们可使用LoginForm[username] 命名 username 特性相应的表单域。

现在剩下的工作就是创建 login 视图了，它应该包含一个带有所需输入项的 HTML 表单。

三、创建表单

编写 login 视图是很简单的，我们以一个 form 标记开始，它的 action 属性应该是前面讲述的 login动作的URL。然后我们需要为 LoginForm类中声明的属性插入标签和表单域。最后，我们插入一个可由用户点击提交此表单的提交按钮。所有这些都可以用纯HTML代码完成。

Yii 提供了几个助手（helper）类简化视图编写。例如，要创建一个文本输入域，我们可以调用 CHtml::textField()；要创建一个下拉列表，则调用 CHtml::dropDownList()。
例如，如下代码将生成一个文本输入域，它可以在用户修改了其值时触发表单提交动作。

CHtml::textField($name,$value,array('submit'=>''));

Copy after login

下面，我们使用 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(); ?>

Copy after login

四、收集表格输入

有时我们想通过批量模式收集用户输入。也就是说，用户可以为多个模型实例输入信息并将它们一次性提交。我们将此称为表格输入（tabular input），因为这些输入项通常以 HTML 表格的形式呈现。

要使用表格输入，我们首先需要创建或填充一个模型实例数组，取决于我们是想插入还是更新数据。然后我们从 $_POST变量中提取用户输入的数据并将其赋值到每个模型。和单模型输入稍有不同的一点就是：我们要使用 $_POST['ModelClass'][$i]提取输入的数据而不是使用 $_POST['ModelClass']。

public function actionBatchUpdate() { // 假设每一项（item）是一个 'Item' 类的实例， // 提取要通过批量模式更新的项 $items=$this->getItemsToUpdate(); if(isset($_POST['Item'])) { $valid=true; foreach($items as $i=>$item) { if(isset($_POST['Item'][$i])) $item->attributes=$_POST['Item'][$i]; $valid=$valid && $item->validate(); } if($valid) // 如果所有项目有效 // ...则在此处做一些操作 } // 显示视图收集表格输入 $this->render('batchUpdate',array('items'=>$items)); }

Copy after login

准备好了这个动作，我们需要继续 batchUpdate 视图的工作以在一个 HTML 表格中显示输入项。