很多人对于淘宝评价的表单 有微词 了，近些天留意收集了下淘宝的评价表单页面。看得出正在不断的改进中，在这里表示关注和支持。
下面看图不说话：
原评价表单
版本一（目前在用的）
版本二
还有一个我以前对于此的评价表单的草图，个人对 版本二 比较满意。不知道大家更倾向于哪个？
YUI 读码日记之 YAHOO.util.Dom - Part.2
继续 在 YAHOO.util.Dom 中徘徊。由于 YAHOO.util.Dom 多次调用 batch 方法，所以先看看这个函数是怎么写的。有关 batch 的用法，可以参见 这里 ，相关的代码如下
batch: function(el, method, o, override) {
// 让 el 始终为 HTMLElement
el = (el && (el.tagName || el.item)) ? el : Y.Dom.get(el);
if (!el || !method) {
return false;
}
// 确定返回的对象
var scope = (override) ? o : window;
// 看起来是个 HTMLElement 或者不是 Array
if (el.tagName || el.length === undefined) {
return method.call(scope, el, o);
}
var collection = [];
for (var i = 0, len = el.length; i < len; ++i) {
collection[collection.length] = method.call(scope, el[i], o);
}
return collection;
},小马补充
batch 是 YUI Dom 库的核心之一。它最大的意义在于，它让 Dom 库的其他大多方法
的第一个参数可以是一个 id / 元素对象 或 一组 id/元素对象，减少了循环的使用。在这里可以找到 call 与 apply 的用法 。在了解了 batch 以后，下来看 YUI.util.Dom 是怎么使用这一方法的，一口气看两个函数
getStyle: function(el, property) {
// toCamel 函数后面介绍
property = toCamel(property);
// 获取节点的样式
var f = function(element) {
return getStyle(element, property);
};
return Y.Dom.batch(el, f, Y.Dom, true);
},setStyle: function(el, property, val) {
property = toCamel(property);
// 设置节点的样式
var f = function(element) {
setStyle(element, property, val);
};
Y.Dom.batch(el, f, Y.Dom, true);
},有关这两个函数的具体用法，可以看下 相关的文档 。其实从参数上就很容易理解怎么使用。看上面的两个函数有利于理解 YAHOO.util.Dom.batch 的调用方式。
接下来，粗略看下 getXY
getXY: function(el) {
var f = function(el) {
// 确定元素是否「肉眼可见」
if ( (el.parentNode === null || el.offsetParent === null ||
this.getStyle(el, 'display') == 'none') &&
el != el.ownerDocument.body) {
return false;
}
return getXY(el);
};
return Y.Dom.batch(el, f, Y.Dom, true);
},getX 与 getY 方法也是调用此函数，只是获取返回值的数组元素不一样。由于浏览器的兼容问题，提供给用户的 YAHOO.util.Dom.getXY 也仅仅是判断变量以后，再扔给最为复杂的内部 getXY 函数。
OK，留下太多的「悬念」了，下一期着重将它们解决。
诡异的 Session 丢失问题
由于服务器损坏 ，所以不得不重新发布网站。当 Anakin 兄弟全部将环境搞定，并且 Gracecode.com 也能正常浏览的时候，我发现我的网站竟然不能登录了。
起初，我怀疑是环境问题，于是我联系 Anakin 兄，他说一切正常。于是，我就开始检查起我的代码，几段 DEBUG 代码下来，我发现竟然连 POST 数据都收不到（var_dump($_POST);），而 GET 是正常的！非常地让人匪夷所思。
继续 DEBUG 发现，我输错了用户名和密码是能 var_dump 出 POST 与 SESSION 的，一切正常。唯独就是我输入正确的用户名与密码以后，老问题就出现了。
经过充分的调试与徘徊以后，我开始静下心来思索 Session 的流程：Session 由客户端的 Cookie（或者是其他验证方式）提供验证值，然后服务器端根据这个值，从文件系统（或者数据库、或者内存文件系统、任何你想得到的媒介）获得对应的值。
那么先从客户端入手，看看是否存在异常。首先，查看客户端是否有保存的 Cookie，的确是有的 -- 这就证明客户端是没有问题的。继续推断，既然客户端方面问题不大，那么问题到底是出在哪里呢？
登录不进去，那么我将判断是否登录的函数修改成始终返回 true（请未成年的小朋友在家长的陪同下操作）。发现登录后台与操作一切都没有问题的，这就说明 POST 过去的数据服务器也是能够接收的。
那么，单从这点上说明，肯定是服务器端的 Session 出了问题。我打印出 Session 的配置，如下图。
根据我的经验，并没有发现配置上有什么异常的地方。此时，我突然有种「邪恶」的想法，于是乎就 DEBUG 了下述的代码
var_dump(is_writeable(ini_get("session.save_path")));
噢，「卖蛋糕、牙膏、×膏药」的！竟然返回的是 false，看来 Anakin 这小子又要被我「诅咒」了。问题终于有了个水落石出的结果，原来新安装好的系统，忘记把 session.save_path 设置成可写的了。这样导致登录成功以后，需要写入的 Session 无法保存在文件系统中，而此时 Session 的的确确有又是 start 的。
绕过这一问题很简单，只需要在 session_start 之前用 session_save_path 设置成自己的某个可读的目录就可以了。
马上联系 Anakin 兄那小子，并将相应的目录修改了回来。证明我的推断是正确的，现在又可以登录进去了。至于 POST 为何无法接收到，在事后也找到了原因，是因为 301 重定向带到了新的页面。
看来，忙乱中，总是会出现不大不小的问题，共勉之。
