易栈网-膘叔

在YII项目实施过程中，遇到一个问题，即，只在某一个module里需要获取IP的来源，并判断具体来自于何处。

默认在yii里取得客户端IP只有一个简单的方法，来自于ChttpRequest类，只是这里只有一个判断，即Remote_addr，而这个，一般来说是不准的，因此，我直接COPY了康盛的IP来源判断。

然后通过那个比较出名的iplocation类读取wry.dat，来获取IP的定位（iplocation仿佛是几年前王总写的还是andot写的？用来分析纯真IP库的。说起这个wry.dat，事实上，它的来源还真是要从以前的一款软件：追捕说起，但那个年代远了，早就消失在历史的长河中了。）

好吧，上面就是我要说的背景，于是，我认为，既然要在module里获取，那么我就在module的init方法里直接实现了吧。

然后，我把具体的获取IP，并且分析IP来源，并到数据库查询以获取Area_id的代码扔在了module 的 init 方法里，然后运行一看，直接502 bad gateway出现了。折腾了好久，发现都一直是502。

但是测试了一下，把这些代码COPY到Controller的action里面，又十分正常（因为没空研究module的实现），于是就把代码COPY到module的beforeAction方法中了。

然后问题解决。（没仔细想为什么，只是纯粹一个记录，让自己知道，尽量不要在init里写上一大堆实现代码。。。）

自己的笔记。。。。

基本上这样就可以实现分页了。。。当然，这是最基础的。因为实在没时间 仔细看zii的CgridView

我在dongbeta的网站上看到了这个东西，突然觉得原来子域名真的很简单，原来我还在想，如何绑定一些子域名的事情呢。

看一下原文吧，然后说明一下，官方的手册中其实已经有类似的介绍了，只是目前这一部分还是英文版的，这可能和这个功能是最新刚加入的关吧。。来源网址为：http://dongbeta.com/view/655

--start--

Yii强大的路由功能配置相当灵活，特别是增加了参数主机名路由功能之后更是可以灵活控制域名。感觉每一次提出一个提议，Yii的开发者qiang如果采纳，就会给出一个我没有想到却更加强大的解决方案。这次就是这样。

下面就是可以将所有子域名都转化为模块的路由规则，来自Yii官方论坛的一个帖子：

在转这篇文章之前，我先说一点项目中遇到的问题，公司的主页最近改版上线，但是上线后出了一点问题，是CSS方面的问题。

CSS文件很多，前端把它分的很细，每一个小的widget部位就是一个单独的CSS文件，这样确实方便了有重复内容时的工作量减轻。于是我们在上线后，对CSS文件进行了合并，用的是Yii的插件 EclientScript（@hightman开发的一个插件）。CSS和JS都顺利合并了，但结果却不太正常。经过仔细检查发现是每个文件头的@charset=utf-8导致了这个问题。合并后，所有的文件内容都被引用到一起，所以造成了合并后的文件中“@charset=utf8”有好几个，但是为了保证文件是按utf-8格式被加载于是保留了最上面的@charset=utf8，其余的都删除了。OK，这时候所有的流量器都正常了。

结果第二天，老板过来说，在IPAD下不正常，于是继续排查，最终发现还是这个@charset=utf8的原因。前面说过，我们只保留了第一个文件的UTF8的判断，其他的都清空了，那为什么还会出错呢？经过测试，发现@charset=utf-8只能在第一行才有效，在其他行时，safari不认，而EClientScript在压缩文件后，会在文件第一行加上这个文件对应实际文件的地址，于是就让@charset=utf8到了第二行。所以IPAD上面显示就不太正常了。。

接下来就转载了：CSS通用元素选择器的都市流言，原文来自：http://shawphy.com/2010/11/css-universal-selector.html

本文尚未有测试数据支持，以下结论仅是根据现有情况的一种解释。

关于 * 这个选择器，一直有个疑惑，到底是否影响效率。在先前的观念中，这由于要匹配所有的元素，让每一个元素都带上这个属性，所以会影响页面的效率。但近来的思考，觉得这应该不会影响效率。为此还特地写过一篇博文，里边提到了这点：真的还需要reset.css么？

而这篇文章中我打算着重阐述为何 * 这个选择器不会影响效率。

上周六去参加了 web标准化交流会，席间 winter 从浏览器（webkit）的角度分享了关于页面渲染的过程。其PPT也可以在前面的链接中下载到。

其中一个很重要的过程是，当页面载入过程中，CSS 和 HTML 是并行下载的。并且通常CSS是在HEAD中引入的，并且体积不如HTML大，所以CSS会先下载完。下载的过程中浏览器就已经开始对CSS中的规则进行 索引，也就是已经确定哪一个元素呈现的样式是如何的了。同时，浏览器根据HTML构建出的DOM树，其中的每一个元素会直接去CSS规则索引中去比对，构 建出渲染树。这个过程都是并行的，并且CSS规则是进行了索引的，因此速度非常的快速。

那么我们看看CSS规则的来源主要有2个，一是浏览器内置的元素样式，Firefox 3.x版是放在目录下的res文件夹内，4.0版和Chrome中没找到（这里是我的主观臆断不太可靠，大家自行辨别），另一个就是页面提供的。根据查看 放在 res 文件夹下的 CSS 文件就可以得知，就是是什么样式都不写，已经为每一个HTML元素设定好了基本样式了。

那么看看我们所忌讳的事情，不用*{margin:0;padding:0}，而是使用

看看这一大坨东西啊，难道不是跟上面的 * 选择器一个用途么？对每个元素（至少是常用元素），添加样式。其实作用是一样的，并且就算没有这一坨，浏览器内置样式也在对每个元素设置样式。之后 HTML 文件中的每一个元素，可以很容易找到自己应当呈现的样式了。

那么，对于之后添加的，会不会有性能影响呢？也不会，由于CSS规则已经确定并索引了，所以今后增加的元素也不过就是简单比对一下而已，不会多走一步的。

所以，由此得出结论，只要有需要，大胆的使用 * 吧，他不会给你从性能上增加额外的麻烦。

最后补两个前端优化小知识：
1，由于CSS规则和HTML是并行载入的，因此把CSS放在HEAD中是非常有必要的。
2，少使用 :last-child 。因为这个选择器无法索引起来，必须等DOM构件完，才能知道他是不是父元素中最后的那个 元素。这种就非常慢了，慎用。

----EOF--

注：文中@charset=utf-8我格式可能写的不对，只是表达一个意思，因为我没有dreamwaver，而所说DW在写CSS的时候，默认会在第一行加上这个玩意。。。

官方的GUIDE里，对于validator的介绍太少了，只有这么一段 ：

7. Validator（验证）

Validator需继承CValidator和实现CValidator::validateAttribute方法。

class MyValidator extends CValidator
{
    protected function validateAttribute($model,$attribute)
    {
        $value=$model->$attribute;
        if($value has error)
            $model->addError($attribute,$errorMessage);
    }
}

即使在这里，http://www.yiiframework.com/doc/api/1.1/CValidator，介绍的也不是特别的多，后来，找到了这个cheatsheet，感觉还不错，对应一下api的内容，感觉有点爽

感谢龙井的回复，使得我注意到了wiki，地址：http://www.yiiframework.com/wiki/56/reference-model-rules-validation/，可以关注一下下哦