飘逸

飘逸

这家伙有点懒,还没写个性签名!

  • 财富值4408
  • 威望值280
  • 总积分8178

个人信息

  • 回答了问题 yii2的JS事件

    YII只是个PHP的框架。并没有对JS进行封装。也完全没有必要封装JS,毕竟有Jquery的存在。

    所以你在引入Jquery之后完全可以依照JQ的写法去书写JS

    当然,你可以控制JS存在于源代码的位置,比如head,body等位置。甚至,你可以把它控制在YII JQ的$(function(){})中。

    PS:你可以在浏览器右键查看源代码以查看其JS最终位置。

    代码看起来就像是酱紫的, 其中\yii\web\View::POS_READY代表着本块JS代码的位置存在于$(function(){})中。

    <?php $this->beginBlock('yourBlockID') ?>
    
    //一些JS代码。可以原生,可以JQ。
    
    <?php $this->endBlock() ?>  
    <?php $this->registerJs($this->blocks['yourBlockID'], \yii\web\View::POS_READY); ?>
    

    你可以在权威指南的 显示数据->操作客户端脚本 以及 应用结构->视图->使用数据块 中得到详细的描述。

  • 2016-08-01 已签到
    连续签到1天,获得了5个金钱
  • 回复了 的说说
    社区还真有几枚文艺小清新啊!!
    主要是俺人长得帅,倒是让阁下见笑了。
  • 回复了 的回答

    load()
    顾名思义,加载。为调用的模型加载从用户那传来的数据用以填充该模型。
    填充的过程是不会使用rules()中声明的验证器去验证的。但是他会把没有在rules()中声明验证器的属性排除在填充之外。
    举个例子:
    假设你拥有 public $haha 属性。
    但是你没有在rules中为$haha声明一个验证器。那么你在调用load()的时候则不会去为$haha填充数据。
    即使这个数据是符合load()数据源的格式的。

    而validate()的责任才是真正去检查每一个被填充了值的属性是否合法。如果不合法,则会往errors属性中填充不合法的信息并返回false。

    其实俺懂得也不多,主要是人长得帅。

  • load()
    顾名思义,加载。为调用的模型加载从用户那传来的数据用以填充该模型。
    填充的过程是不会使用rules()中声明的验证器去验证的。但是他会把没有在rules()中声明验证器的属性排除在填充之外。
    举个例子:
    假设你拥有 public $haha 属性。
    但是你没有在rules中为$haha声明一个验证器。那么你在调用load()的时候则不会去为$haha填充数据。
    即使这个数据是符合load()数据源的格式的。

    而validate()的责任才是真正去检查每一个被填充了值的属性是否合法。如果不合法,则会往errors属性中填充不合法的信息并返回false。

  • 回复了 的回答

    safe验证器和其他验证器比如email,url是一个级别的,没有任何特殊之处的。如果非要说特别之处,那就是如果在相同场景下对相同的属性声明一次email规则和safe规则,那么生效的会是email。

    所以说真正决定在一个场景中一个验证器是否生效的是当前场景是否包含了该验证器所验证的属性以及该验证器的属性是否指定了生效场景。

    有如下几种主要情况及对应结果

    1。一个场景没有声明任何验证属性,仅仅是个空数组,但rules()却有无穷无尽的验证规则。 结果:使用该场景的model调用validate()不会进行任何的验证。

    2。一个场景声明了一些属性,一些属性没有声明应用场景。 结果:该场景所包含的属性如果在这些没有声明场景的属性里,则依旧会被得到验证。 所以没有声明场景的属性会得到所有声明该属性的场景的关爱。

    3。一些属性指定了应用场景,但不是该场景的另外一个场景也声明了这个属性。 结果:后者的场景无法进行验证,毕竟他的所爱已经心有所属。

    所以说楼主的email的safe 会被所有声明email属性的场景使用。但由于之前提到的email的权重比safe大。所以create和update场景呈现出来的是对email属性进行了email验证器的验证。

    主要是人长得帅。不用谢啦。

  • safe验证器和其他验证器比如email,url是一个级别的,没有任何特殊之处的。如果非要说特别之处,那就是如果在相同场景下对相同的属性声明一次email规则和safe规则,那么生效的会是email。

    所以说真正决定在一个场景中一个验证器是否生效的是当前场景是否包含了该验证器所验证的属性以及该验证器的属性是否指定了生效场景。

    有如下几种主要情况及对应结果

    1。一个场景没有声明任何验证属性,仅仅是个空数组,但rules()却有无穷无尽的验证规则。 结果:使用该场景的model调用validate()不会进行任何的验证。

    2。一个场景声明了一些属性,一些属性没有声明应用场景。 结果:该场景所包含的属性如果在这些没有声明场景的属性里,则依旧会被得到验证。 所以没有声明场景的属性会得到所有声明该属性的场景的关爱。

    3。一些属性指定了应用场景,但不是该场景的另外一个场景也声明了这个属性。 结果:后者的场景无法进行验证,毕竟他的所爱已经心有所属。

    所以说楼主的email的safe 会被所有声明email属性的场景使用。但由于之前提到的email的权重比safe大。所以create和update场景呈现出来的是对email属性进行了email验证器的验证。

  • 赞了说说
    初学者 加油!!
  • 2016-07-29 已签到
    连续签到3天,获得了15个金钱
  • 回复了 的说说
    这周问答的权限出了些状况,耽误大家采纳答案了,现在可以正常采纳了,感谢提出此问题的同学
    也就是人长得帅点,不用特意感谢啦。
副总裁 等级规则
8178/10000
资料完整度
10/100
用户活跃度
0/100

Ta的关注

15

Ta的粉丝

22

Ta的访客

68