Yii Framework Official Guide Series 17--using forms: Creating Models

Before we write the HTML code needed for a form, we should first determine the type of data that comes from the end user and what rules the data should conform to. Model classes can be used to record this information. As defined in the model chapters, the model is the central location for saving user input and validating these inputs.

We can create two types of models, depending on how you use the data entered by the user. If the user input is collected, used and then discarded, we should create a form model; If the user's input is collected and saved to the database, we should use an Active Record. The two types of models share the same base class, CModel, which defines the common interfaces required for the form.

Note: We use the form model primarily in the example in this section. However, the same operation can also be applied to the Active Record model.

1. Defining Model Classes

Below we create a LoginForm model class to collect the user's input in a login page. Because the login information is only used to authenticate the user and does not need to be saved, we will LoginForm create it as a form model.

Class LoginForm extends cformmodel{public    $username;    public $password;    Public $rememberMe =false;}

LoginFormThree attributes are defined in: $username , $password and $rememberMe . They are used to save user-entered user names and passwords, and whether the user wants to remember his login options. Because $rememberMe there is a default value false , the corresponding option will be unchecked when the initialization is displayed in the login form.

Information: We refer to these member variables as attributes ( attributes) rather than attributes (properties) to distinguish them from normal attributes (properties). An attribute (attribute) is a property that is primarily used to store data from user input or database (propertiy).

2. Declaring validation rules

Once the user submits his input and the model is populated, we need to make sure that the user's input is valid before use. This is done by validating the user's input and a series of rules. We rules() specify these validation rules in the method, and this method should return a rule configuration array.

Class LoginForm extends cformmodel{public    $username;    public $password;    Public $rememberMe =false;    Private $_identity;    Public function rules ()    {        return array (            ' username, password ', ' required '),            array (' RememberMe ' , ' Boolean '),            Array (' Password ', ' Authenticate '),        );    Public function Authenticate ($attribute, $params)    {        $this->_identity=new useridentity ($this Username, $this->password);        if (! $this->_identity->authenticate ())            $this->adderror (' password ', ' wrong user name or password. ');    }}

The above code specifies: username and is password required, password should be verified (authenticated), rememberMe should be a Boolean value.

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

Array (' AttributeList ', ' Validator ', ' on ' = ' scenariolist ', ... Additional options)

AttributeList（特性列表）This is the list of attributes that need to be validated by this rule, with each attribute name separated by commas; Validator（验证器） Specifies the kind of validation to perform; The on parameter is optional, which specifies the list of scenes to which this rule should be applied; an additional option is an array of name values that initializes the property values of the corresponding validator.

There are three ways to specify in validation rules Validator .

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

/** * @param the name of the attribute to be validated by String * @param the option specified in the array validation rule */public function Validatorname ($attribute, $params) {...}

Second, Validator it can be the name of a validator class , and when this rule is applied, an instance of a validator class is created to perform the actual validation. Additional options in the rule are used to initialize the property values of the instance. The validator class must inherit from Cvalidator.

Third, Validator you can be an alias for a predefined validator class . In the example above, the required name is the alias of Crequiredvalidator, which is used to ensure that the attribute value being validated is not NULL. The following is a complete list of predefined authenticator aliases:

• boolean: Cbooleanvalidator alias to ensure that the attribute has a cbooleanvalidator::truevalue or cbooleanvalidator::falsevalue value.

• captcha: Ccaptchavalidator alias, ensure that the attribute value is equal to the verification code shown in CAPTCHA.

• compare: Ccomparevalidator alias to ensure that the attribute equals another attribute or constant.

• email: Cemailvalidator alias, ensure that the feature is a valid email address.

• default: Cdefaultvaluevalidator alias that specifies the default value for the attribute.

• exist: Cexistvalidator aliases to ensure that the attribute values can be found in the columns of the specified table.

• file: Cfilevalidator alias, ensure that the feature contains an upload file name.

• filter: The alias of Cfiltervalidator, which changes this feature through a filter.

• in: Crangevalidator aliases to ensure that the data is within the range of a pre-specified value.

• length: Cstringvalidator alias to ensure that the length of the data is within a specified range.

• match: The alias of the Cregularexpressionvalidator to ensure that the data matches a regular expression.

• numerical: Cnumbervalidator alias to ensure that the data is a valid number.

• required: Crequiredvalidator alias to ensure that the attribute is not empty.

• type: Ctypevalidator alias to ensure that the attribute is the specified data type.

• unique: A cuniquevalidator alias that ensures that the data is unique in the data table column.

• url: Curlvalidator alias to ensure that the data is a valid URL.

Here are a few examples of these pre-defined validators:

User name is required array (' username ', ' required '),//username must be between 3 and 12 characters in Array (' username ', ' length ', ' min ' =>3, ' Max ' =>12),//In In the registration scenario, the password password must be consistent with PASSWORD2. Array (' password ', ' compare ', ' compareattribute ' = ' password2 ', ' on ' = ' register '),//In the login scenario, the password must be validated. Array (' Password ', ' Authenticate ', ' on ' = ' login '),

3. Security-Specific value assignment

After an instance of a class is created, we usually need to populate its attributes with the data submitted by the end user. This can be done easily with the following block assignment (massive assignment):

$model =new loginform;if (isset ($_post[' loginform '))    $model->attributes=$_post[' loginform '];

The final expression is called a block assignment (massive assignment) , which $_POST['LoginForm'] copies each item in the corresponding model attribute. This is equivalent to the following assignment method:

foreach ($_post[' LoginForm ') as $name + = $value) {    if ($name is a security feature)        $model $name = $value;}

It is important to detect the security of an attribute, for example, if we assume that the primary key of a table is safe and expose it, then an attacker could gain an opportunity to modify the record's primary key, thereby tampering with the content that was not authorized to him.

The policy for detecting feature security is different in versions 1.0 and 1.1, which we will explain separately below:

Security features in 1.1

In version 1.1, an attribute is considered safe if it appears in a validation rule in the appropriate scenario. For example:

Array (' Username, password ', ' required ', ' on ' = ' login, register '), array (' email ', ' required ', ' on ' = ' register '),

As shown above, username and the password attribute login is required in the scene. usernameand, password and email attributes register are required in the scene. So, if we login execute the block assignment in the scene, only the username and the block will be assigned to the password value. Because only they appear in login the validation rules. On the other hand, if the scene is register , these three attributes can all be assigned to a block.

$model=new User (' login ') in the login scenario, if (Isset ($_post[' user '))    $model->attributes=$_post[' user '];//in the registration scenario $ Model=new User (' register '), if (Isset ($_post[' user '))    $model->attributes=$_post[' user '];

So why do we use such a strategy to detect the security of a feature? The rationale behind this is this: If a feature already has one or more validation rules that can detect validity, what are we worried about?

Keep in mind that validation rules are used to check the data entered by the user, rather than checking the data we generate in the code (such as timestamps, auto-generated primary keys). Therefore, do not add validation rules for attributes that do not accept end-user input.

Sometimes we want to declare that a feature is safe, even if we don't specify any rules for it. For example, the content of an article can accept any input from the user. We can use special safe rules to accomplish this:

Array (' content ', ' safe ')

For the sake of completion, there is also a rule that declares a property to be unsafe unsafe :

Array (' permission ', ' unsafe ')

unsafeRules are not commonly used, it is an exception to the security features we defined earlier.

Security Features in 1.0

In version 1.0, determines whether a data item is safe, based on a safeAttributes given scene named the return value of the method and the data item. By default, this method returns all public member variables as the security attribute of the Cformmodel, and it also returns all the field names in the table in addition to the primary key as Cactiverecord security features. We can override this method to restrict security features based on the scenario. For example, a user model can contain many features, but in a login scene. We can only use username and password attribute it as follows:

Public Function Safeattributes () {    return Array (        parent::safeattributes (),        ' login ' = ' username ', Password ',    );}

safeAttributesThe more accurate return value of the method should be structured as follows:

Array (   //These attributes can be massively assigned in no scenario//That's not explicitly specified below
  
    ' attr1, attr2, ... ',     *   //These attributes can be massively assigned @ Scenario 1   ' scenario1 ' + ' a TTR2, ATTR3, ... ',     *   //These attributes can be massively assigned @ Scenario 2   ' Scenario2 ' + ' at TR1, ATTR3, ... ',)
  

If the model is not scene-sensitive (for example, it is used only in one scene, or if all the scenes share a set of identical security features), the return value can be a simple string like the following.

' Attr1, attr2, ... '

For those insecure data items, we need to use separate assignment statements to assign them to the corresponding attributes. As shown below:

$model->permission= ' admin '; $model->id=1;

4. Trigger Validation

Once the model is populated with data submitted by the user, we can invoke the Cmodel::validate () departure data validation process. This method returns a value that indicates whether the validation was successful. For the Cactiverecord model, validation can also be triggered automatically when we call its Cactiverecord::save () method.

We can use scenario to set the scene properties so that the validation rules for the corresponding scene will be applied.

Validation is performed based on the scenario. The Scenario property specifies the scene currently used by the model and the set of validation rules currently in use. For example, in the login scenario, we just want to validate the and input in the user model, and username password in the register scenario, we need to validate more input, such email address as, and so on. The following example shows how to register perform validation in a scene:

Create a User model in the registration scenario  . Equivalent to://$model =new user;//$model->scenario= ' register '; $model =new User (' register ');//fill the input values into the model $model-> attributes=$_post[' User '];//performs validation if ($model->validate ())   //If the inputs is valid    ... else ...    

The scene associated with the rule can be specified by the options in the rule on . If the on option is not set, the rule is applied to all scenarios. For example:

Public Function Rules () {    return array (        ' username, password ', ' required '),        array (' Password_repeat ' , ' Required ', ' on ' = ' register '),        Array (' password ', ' compare ', ' on ' = ' register '),    );

The first rule applies to all scenarios, and the second will only be applied to the register scene.

5. Extract Validation Errors

When validation is complete, any errors that may be generated will be stored in the model object. We can extract these error messages by calling Cmodel::geterrors () and Cmodel::geterror (). The difference between the two methods is that the first method returns error information for all model attributes, and the second returns only the first error message.

6. Feature Labels

When designing a form, we usually need to display a label for each form field. The tag tells the user what information he should fill out in this form field. Although we can hardcode a label in the view, it is more flexible and convenient if we specify (label) in the corresponding model.

By default CModel will simply return the name of the attribute as its label. This can be customized by overriding the Attributelabels () method. As we'll see in the next sections, assigning tags in the model will allow us to create more powerful forms faster.

The above is the official Yii Framework Guide Series 17--Use forms: Create the content of the model, and see more about topic.alibabacloud.com (www.php.cn)!

