1.yii提供了强大的数据库编程支持。yii数据访问对象(DAO)简历在php的数据对象(PDO)exteension上，使得在一个单一的统一的接口可以访问不同的数据库管理系统（dbms）。使用yii的DAO开发的应用程序可以很容易的切换使用不同的数据库管理系统，而不需要修改数据访问代码
2. yii中views视图中常见的类似这句话<?php echo Yii::t('campaign', 'Campaign Management')?> 括号中的意思是:campaign是指先找到protected\messages\zh_cn文件夹下的campaign.php文件，然后再找到:campaign文件中的数组中的 '”Campaign Management'=>'广告活动管理',“这句话
<?php
return array(
'campaignId'=>'广告活动ID',
'campaignId Error'=>'请选择广告活动',
'advertiserId'=>'广告主',
'advertiserId Error'=>'请选择广告主',
'Campaign Management'=>'广告活动管理',
'Campaign View'=>'广告活动查看',
'Campaign Edit'=>'广告活动编辑',
'' => '',
'' => '',
'' => '',
);
3.
is_numeric — 检测变量是否为数字或数字字符串
4.
Yii::app()介绍
$form = $this->beginWidget ( 'CActiveForm', array (
'id' => 'create-form',
'action' => $this->createUrl ( 'campaign/create/campaignId/'.$campaignId ),
'method'=>'POST',
'enableAjaxValidation' => false
) );
?>
基于CFormModel 的Model
编写表单需要的HTML之前，我们需要决定我们希望用户输入哪些数据，以及应该符合什么规则。一个模型类可以用来记录这些信息，模型是保持用户输入并进行验证的核心
根据我们如何使用用户的输入，我们可以创建两种类型的模型。如果用户输入的数据被收集，使用，然后丢弃，我们将创建一个表单模型（form model）；如果用户输入的数据被保存到数据库中，我们则会使用 active record 。这两种模型都继承了他们相同的基类CModel中定义的表单的通用接口。
1) 模型类的定义
下面的例子中，我们创建了一个LoginForm模型，用来收集用户在登陆页面的输入。由于登陆信息仅仅用于用户验证，并不需要保存，因此我们用form model创建
{
public $username;
public $password;
public $rememberMe=false;
}
LoginForm一共声明了三个属性(attributes)，$username、$password、$rememberMe
用来记录用户输入的用户名、密码、以及是否记住登陆的选项。因为$rememberMe有了默认值false，所以显示表单时对应的选框是没有勾选的。
提示：我们使用名"attributes"，而不是"properties",来把他们和正常的属性(properties)进行区分。
2) 声明验证规则
一旦把用户提交的数据填充到模型，在使用之前，我们要检查他们是否合法。这是通过对输入进行一组规则验证实现的。我们在rulers()方法中通过配置一个数组来定义验证规则，
{
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)
{
if(!$this->hasErrors()) // we only want to authenticate when no input errors
{
$this->_identity=new UserIdentity($this->username,$this->password);
if(!$this->_identity->authenticate())
$this->addError('password','Incorrect password.');
}
}
}
上面的代码指明了用户名和密码是必须得，密码需要被验证，rememberMe必须是布尔型
rules()中返回的每条规则，必须按照如下格式
array('AttributeList', 'Validator', 'on'=>'ScenarioList', ...附加选项（additional options）)
AttributeList 是一个被逗号分隔的需要验证的属性名列表。Validator 指出了需要做怎样的验证。可选的on 参数指出了该规则应用的场景列表，（additional options）是对应的name-value，用于初始对应验证器的相关属性
在一个规则中指定Validator有三种方法，首先Validator可以使该类的一个方法，比如上面例子中的authenticate。该Validator方法必须按照如下的格式声明
* @param string the name of the attribute to be validated
* @param array options specified in the validation rule
*/
public function ValidatorName($attribute,$params) { ... }
其次 Validator 可以使验证器的类名，当规则适用时，一个验证器类的实例会被创建并进行实际的验证。规则里的附加属性，用于初始实例的相关属性。验证器类必须继承于CValidator
提示：当对active record模型指定规则的时候，我们可以使用特殊的参数‘on’，
该参数可以使'insert' 或者 'update'，可以让规则分别在插入或者更新的时候适用。如果没有生命，该规则会在任何调用save()的时候适用。
第三、Validator 可以使验证器类预先定义的别名。在上面的例子中，“required”便是CRequiredValidator的别名，用来验证属性不能为空。下面是预定义的验证器类别名的列表
• boolean：CBooleanValidator的别名，验证属性的值是否是CBooleanValidator::trueValue 或者 CBooleanValidator::falseValue
• captcha：CCaptchaValidator的别名，验证属性的值是否和CAPTCHA中显示的验证码的值相等
• compare：CCompareValidator的别名，验证属性的值是否等于另一个属性或者一个常量
• email：CEmailValidator的别名，验证属性的值是否是个合法的email地址
• 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'),
// username must be between 3 and 12 characters
array('username', 'length', 'min'=>3, 'max'=>12),
// when in register scenario, password must match password2
array('password', 'compare', 'compareAttribute'=>'password2',
'on'=>'register'),
// when in login scenario, password must be authenticated
array('password', 'authenticate', 'on'=>'login'),
3) 安全属性的设置
当一个模型创建之后，我们往往需要根据用户的输入，为它填充属性。这可以方便的通过下面批量赋值的方式来实现
if(isset($_POST['LoginForm']))
$model->attributes=$_POST['LoginForm'];
最后那条语句便是批量赋值，把$_POST['LoginForm']中每个属性都赋值到对应的模型属性中，它等价于下面的语句
foreach($_POST['LoginForm'] as $name=>$value){
if($name is a safe attribute)
$model->$name=$value;
}
声明属性是否是安全属性是个至关重要的工作。例如，如果我把把数据表的主键暴露为安全属性，那么便可以通过修改主键的值，来管理本没有权限管理的数据，进行攻击。
4) 1.1版中的安全属性
在1.1版中，如果属性在适用的规则中指定了验证器，则认为是安全的。例如
array('email', 'required', 'on'=>'register'),
上面的代码中用户名和密码属性在login的场景下不允许为空。用户名、密码邮箱在register的场景下不允许为空。因此如果在login的场景下进 行批量赋值，仅仅用户名和密码会被赋值，因为login场景下验证规则里仅出现了这两个属性，但是如果是在register场景下，那么这三个属性都会被 赋值。
// in login scenario$model=new User('login');
if(isset($_POST['User']))
$model->attributes=$_POST['User'];
// in register scenario
$model=new User('register');
if(isset($_POST['User']))
$model->attributes=$_POST['User'];
那么为什么我们使用如此的策略来决定一个属性是否是安全属性呢？因为一个属性，已经有了一个或者多个对个进行校验的规则，那么我还需要担心吗？
需要记住的是，验证器是用来检测用户输入的数据，而不是我们用代码产生的数据（例如 时间戳，自增的主键等）。因此不要给那些不需要用户输入的属性添加验证器。
有时候我们想声明一些属性为安全属性，但是又不必给指定一个验证规则。例如文章的正文属性，我们可以允许用户的任何输入。为了实现这个目标，我们可以用safe规则。
array('content', 'safe')
对应的也有一个unsafe规则，来指定哪些属性是不安全的
array('permission', 'unsafe')
unsafe并不常用，对你以前定义的安全属性来说，这是个例外
5) 获取验证错误
当验证结束后，任何可能的错误都存储在模型的实例中。我们可以通过调用CModel::getErrors() 和 CModel::getError()重新获取到。这两个方法的区别在于，第一个可以返回指定模型属性的所有错误，而第二个方法只返回了第一条错误。
6) 属性标签
设计表单的时候，我们需要为用户的输入框显示一个标签，来提示用户输入。尽管我们可以再form中写死，但是如果我们在相应的模型中指定的话会更加方便和灵活
默认情况下，CModel 会简单的返回属性的名字作为标签。这可以通过重写attributeLabels() 方法来自定义。在接下来章节中我们将看到,在模型中指定标签可以让我们更快更强大的创建一个form表单
扫一扫
601
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
