Yii 프레임워크 공식 가이드 시리즈 17 - 양식 사용: 모델 생성

양식에 필요한 HTML 코드를 작성하기 전에 먼저 최종 사용자 입력에서 오는 데이터 유형과 데이터가 무엇인지 결정해야 합니다. 그러한 규칙을 따르십시오. 모델 클래스를 사용하여 이 정보를 기록할 수 있습니다. 모델 장에서 정의한 대로 모델은 사용자 입력을 저장하고 해당 입력을 검증하는 중앙 위치입니다.

사용자가 입력한 데이터가 어떻게 사용되는지에 따라 두 가지 유형의 모델을 만들 수 있습니다. 사용자 입력을 수집하고 사용한 다음 삭제하는 경우 양식 모델을 만들어야 하며, 사용자 입력을 수집한 후 데이터베이스에 저장하는 경우 활성 레코드를 사용해야 합니다. 두 가지 유형의 모델 모두 양식에 필요한 공통 인터페이스를 정의하는 동일한 기본 클래스 CModel을 공유합니다.

참고: 이 섹션의 예에서는 주로 양식 모델을 사용합니다. 그러나 Active Record 모델에도 동일한 작업이 적용될 수 있습니다.

1. 모델 클래스 정의

아래에서는 로그인 페이지에서 사용자 입력을 수집하기 위한 LoginForm 모델 클래스를 만듭니다. 로그인 정보는 사용자 인증을 위해서만 사용되며 저장할 필요가 없으므로 폼 모델로 LoginForm을 생성하겠습니다.

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

LoginForm는 $username, $password 및 $rememberMe의 세 가지 속성을 정의합니다. 이는 사용자가 입력한 사용자 이름과 비밀번호를 저장하는 데 사용되며 사용자가 자신의 로그인을 기억하려는 경우에도 사용할 수 있습니다. $rememberMe의 기본값은 false이므로 로그인 양식에 처음 표시될 때 해당 옵션이 선택 취소됩니다.

정보: 이러한 멤버 변수를 일반 속성과 구별하기 위해 속성 대신 속성이라고 부릅니다. 속성은 주로 사용자 입력이나 데이터베이스의 데이터를 저장하는 데 사용되는 속성입니다.

2. 유효성 검사 규칙 선언

사용자가 입력을 제출하고 모델이 채워지면 사용하기 전에 사용자의 입력이 유효한지 확인해야 합니다. 이는 일련의 규칙에 대해 사용자 입력을 검증함으로써 달성됩니다. 규칙 구성 배열을 반환해야 하는 rules() 메서드에 이러한 유효성 검사 규칙을 지정합니다.

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

    private $_identity;

    public function rules()
    {
        return array(
            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','错误的用户名或密码。');
    }
}

위 코드는 username 및 password가 필수이며 password를 확인해야 함을 지정합니다( 인증됨), rememberMe은 부울 값이어야 합니다.

rules() 반환된 각 규칙은 다음 형식이어야 합니다.

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

여기서 AttributeList（特性列表）는 이 규칙으로 확인해야 하는 기능의 목록 문자열입니다. 각 기능 이름은 쉼표로 구분됩니다. Validator（验证器）는 수행할 확인 유형을 지정하고 on 매개변수는 선택 사항입니다. 규칙이 적용되어야 합니다. 추가 옵션은 해당 유효성 검사기의 속성 값을 초기화하는 데 사용되는 이름-값 쌍의 배열입니다.

유효성 검사 규칙에 Validator을 지정하는 방법에는 세 가지가 있습니다.

먼저 Validator는 위 예시의 처럼 모델 클래스 authenticate에 있는 메서드의 이름일 수 있습니다. 검증 방법은 다음 구조여야 합니다.

/**
 * @param string 所要验证的特性的名字
 * @param array 验证规则中指定的选项
 */
public function ValidatorName($attribute,$params) { ... }

둘째, Validator는 검증자가 될 수 있습니다. 클래스의 이름입니다. 이 규칙이 적용되면 실제 유효성 검사를 수행하는 유효성 검사기 클래스의 인스턴스가 생성됩니다. 규칙의 추가 옵션은 인스턴스의 속성 값을 초기화하는 데 사용됩니다. Validator 클래스는 CValidator에서 상속되어야 합니다.

셋째, Validator은 미리 정의된 유효성 검사기 클래스 의 별칭일 수 있습니다. 위의 예에서 required 이름은 유효성을 검사하는 속성 값이 비어 있지 않은지 확인하는 데 사용되는 CRequiredValidator의 별칭입니다. 다음은 사전 정의된 유효성 검사기 별칭의 전체 목록입니다.

• boolean: CBooleanValidator에 대한 별칭입니다. 속성에 CBooleanValidator::trueValue 또는 CBooleanValidator::falseValue 값이 있는지 확인하세요.

• captcha: CCaptchaValidator의 별칭으로, 속성 값이 CAPTCHA에 표시된 확인 코드와 동일한지 확인합니다.

• compare: CCompareValidator의 별칭으로, 속성이 다른 속성 또는 상수와 동일하도록 보장합니다.

• email: CEmailValidator의 별칭, 속성이 유효한 이메일 주소인지 확인합니다.

• default: CDefaultValueValidator의 별칭, 속성의 기본값을 지정합니다.

• exist: CExistValidator 的别名，确保特性值可以在指定表的列中可以找到。

• file: CFileValidator 的别名，确保特性含有一个上传文件的名字。

• filter: CFilterValidator 的别名，通过一个过滤器改变此特性。

• in: CRangeValidator 的别名，确保数据在一个预先指定的值的范围之内。

• length: CStringValidator 的别名，确保数据的长度在一个指定的范围之内。

• match: CRegularExpressionValidator 的别名，确保数据可以匹配一个正则表达式。

• numerical: CNumberValidator 的别名，确保数据是一个有效的数字。

• required: CRequiredValidator 的别名，确保特性不为空。

• type: CTypeValidator 的别名，确保特性是指定的数据类型。

• unique: CUniqueValidator 的别名，确保数据在数据表的列中是唯一的。

• url: CUrlValidator 的别名，确保数据是一个有效的 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'),

3. 安全的特性赋值

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

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

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

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

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

检测特性安全的策略在版本 1.0 和 1.1 中是不同的，下面我们将分别讲解：

1.1 中的安全特性

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

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

如上所示， 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'];

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

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

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

array('content', 'safe')

为了完成起见，还有一个用于声明一个属性为不安全的 unsafe 规则：

array('permission', 'unsafe')

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

1.0 中的安全特性

在版本1.0中,决定一个数据项是否是安全的,基于一个名为 safeAttributes 方法的返回值和数据项被指定的场景. 默认的,这个方法返回所有公共成员变量作为 CFormModel 的安全特性,而它也返回了除了主键外, 表中所有字段名作为 CActiveRecord的安全特性.我们可以根据场景重写这个方法来限制安全特性 .例如, 一个用户模型可以包含很多特性,但是在 login 场景.里,我们只能使用 username 和 password 特性.我们可以按照如下来指定这一限制 :

public function safeAttributes()
{
    return array(
        parent::safeAttributes(),
        'login' => 'username, password',
    );
}

safeAttributes 方法更准确的返回值应该是如下结构的 :

array(
   // these attributes can be massively assigned in any scenario
   // that is not explicitly specified below
   'attr1, attr2, ...',
     *
   // these attributes can be massively assigned only in scenario 1
   'scenario1' => 'attr2, attr3, ...',
     *
   // these attributes can be massively assigned only in scenario 2
   'scenario2' => 'attr1, attr3, ...',
)

如果模型不是场景敏感的(比如,它只在一个场景中使用,或者所有场景共享了一套同样的安全特性),返 回值可以是如下那样简单的字符串.

'attr1, attr2, ...'

而那些不安全的数据项,我们需要使用独立的赋值语句来分配它们到相应的特性.如下所示:

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

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())   // if the inputs are valid
    ...
else
    ...

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

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

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

5. 提取验证错误

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

6. 特性标签

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

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

以上就是Yii框架官方指南系列17——使用表单：创建模型的内容，更多相关内容请关注PHP中文网（www.php.cn）！