十/100
jQuery, working with PHP
5年前，我刚刚学习PHP这们编程语言的时候，我就放弃了学习很多前端技术，比如javascript和css。总是把所有精力放在服务器端的配置，开发和数据库的设计以及优化上。五年时间过去后，唯一的收获是对服务器端技术比较熟悉，但是开发出来的应用总是感觉缺少点什么。再后来发现了前端技术的重要性，因为前端技术的可优化余地要远远大于后端。于是恶补了一大堆js和css的优化和浏览器的工作行为理论。但越来越发觉自己做出来的应用“难以使用”了，我相信很多服务端技术开发的朋友跟我有同样的感觉。
首先，由于我们缺乏对javascript的熟练编写，导致一个应用很多时候都是借助服务器端完成（以下都以PHP为例），也就是说用户的浏览器只是在GET和POST数据，然后渲染HTML，很少用客户端来进行计算和交互，最多只是用来检测下表单的合法性。记得四年前开发一个CMS的时候，用javascript写了大量的代码，至今想起来犹如梦魇。那时对javascript很不了解，用PHP的思维去使用它，造成代码冗长，难以维护，加上自己调试能力不好，每次做bug修复的时候都想告别这个行业。08年初，在使用Drupal这个CMS的时候，意外看到了jQuery这个框架，是内置在Drupal中的，默认自动加载。为了编写好很多ajax应用，啃了几天jquery cookbook，算是入门了，后来也闲置了。最多就是写一些简单的ajax应用和前台效果。前几天看了一本书《jQuery with PHP》，09年10月份出版的，面向的主要读者就是做服务端开发，对前端知识比较少了解的人。200多页比较精简，语言通俗易懂，看完后收获颇多，从书中摘取一些比较有意思的东西分享给大家。（附上个人翻译，有误的地方欢迎拍转）我想这本书是对一个PHP工程师来说，平衡前后端能力，提高产品的用户体验，节省网络带宽，提高应用性能的重要一课。
It would be silly if a 3D screen was generated on the server and was sent to the client 24 times per second. And it would be awkward if you tried to do something like walk through a wall, and had to wait for the server to decide if it was allowed or not.
（这里用网游来比喻前端和后端的关系，很多程序员都玩网游吧！）
如果3D效果的显示数据是在服务端生成后以每秒24次的频率发送给客户端，可想这种设计有多傻。同样，如果你试着做一些很常见的操作，比如准备穿越一道墙，如果这个时候还要等待服务器来判断是否允许的话同样很傻，客户端做这个事情是最合适的。
However, in a pure PHP environment, that’s exactly what has been happening—the server generates absolutely everything that the client displays. If an element needs to be removed from a table, for example, then the server needs to be told, so that it can give the client the new view. If you try to do something illegal, such as submit a blank form where an email address is required, then pure PHP applications will let you do that, wasting time and server resources.
然而，在单独的PHP环境中，服务端产生几乎所有客户端要显示的东西。比如要从一个HTML表格中删除一个元素，必须通知服务器，这样服务端才能生成新的页面发送给客户端。如果你做了一些非法操作，比如没有填写重要的邮件地址就提交了一个空的表单，只有提交后PHP才能知道，这样大大浪费了时间和宝贵的服务器资源。
However, using JavaScript, and especially using Ajax, the client side is no longer a ”dumb terminal” for the server. We can write applications fully on the client side, if we wish, using the server purely as a database. This book will demonstrate ways to work towards that.
十一/090
Javascript可否多线程
JavaScript的setTimeout与setInterval是两个很容易欺骗别人感情的方法,因为我们开始常常以为调用了就会按既定的方式执行, 我想不少人都深有同感, 例如
setTimeout( function(){ alert(’你好!’); } , 0);
setInterval( callbackFunction , 100);
认为setTimeout中的问候方法会立即被执行,因为这并不是凭空而说,而是JavaScript API文档明确定义第二个参数意义为隔多少毫秒后,回调方法就会被执行. 这里设成0毫秒,理所当然就立即被执行了.
同理对setInterval的callbackFunction方法每间隔100毫秒就立即被执行深信不疑!
但随着JavaScript应用开发经验不断的增加和丰富,有一天你发现了一段怪异的代码而百思不得其解:
div.onclick = function(){
setTimeout( function(){document.getElementById(’inputField’).focus();}, 0);
};
既然是0毫秒后执行,那么还用setTimeout干什么, 此刻, 坚定的信念已开始动摇.
直到最后某一天 , 你不小心写了一段糟糕的代码:
setTimeout( function(){ while(true){} } , 100);
setTimeout( function(){ alert(’你好!’); } , 200);
setInterval( callbackFunction , 200);
第一行代码进入了死循环,但不久你就会发现,第二,第三行并不是预料中的事情,alert问候未见出现,callbacKFunction也杳无音讯!
这时你彻底迷惘了,这种情景是难以接受的,因为改变长久以来既定的认知去接受新思想的过程是痛苦的,但情事实摆在眼前,对JavaScript真理的探求并不会因为痛苦而停止,下面让我们来展开JavaScript线程和定时器探索之旅!
拔开云雾见月明
出现上面所有误区的最主要一个原因是:潜意识中认为,JavaScript引擎有多个线程在执行,JavaScript的定时器回调函数是异步执行的.
而事实上的,JavaScript使用了障眼法,在多数时候骗过了我们的眼睛,这里背光得澄清一个事实:
JavaScript引擎是单线程运行的,浏览器无论在什么时候都只且只有一个线程在运行JavaScript程序.
JavaScript引擎用单线程运行也是有意义的,单线程不必理会线程同步这些复杂的问题,问题得到简化.
那么单线程的JavaScript引擎是怎么配合浏览器内核处理这些定时器和响应浏览器事件的呢?
下面结合浏览器内核处理方式简单说明.
浏览器内核实现允许多个线程异步执行,这些线程在内核制控下相互配合以保持同步.假如某一浏览器内核的实现至少有三个常驻线 程:javascript引擎线程,界面渲染线程,浏览器事件触发线程,除些以外,也有一些执行完就终止的线程,如Http请求线程,这些异步线程都会产 生不同的异步事件,下面通过一个图来阐明单线程的JavaScript引擎与另外那些线程是怎样互动通信的.虽然每个浏览器内核实现细节不同,但这其中的 调用原理都是大同小异.
由图可看出,浏览器中的JavaScript引擎是基于事件驱动的,这里的事件可看作是浏览器派给它的各种任务,这些任务可以源自 JavaScript引擎当前执行的代码块,如调用setTimeout添加一个任务,也可来自浏览器内核的其它线程,如界面元素鼠标点击事件,定时触发 器时间到达通知,异步请求状态变更通知等.从代码角度看来任务实体就是各种回调函数,JavaScript引擎一直等待着任务队列中任务的到来.由于单线 程关系,这些任务得进行排队,一个接着一个被引擎处理.
上图t1-t2..tn表示不同的时间点,tn下面对应的小方块代表该时间点的任务,假设现在是t1时刻,引擎运行在t1对应的任务方块代码内,在这个时间点内,我们来描述一下浏览器内核其它线程的状态.
t1时刻:
GUI渲染线程:
该线程负责渲染浏览器界面HTML元素,当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时,该线程就会执行.本文虽然重 点解释JavaScript定时机制,但这时有必要说说渲染线程,因为该线程与JavaScript引擎线程是互斥的,这容易理解,因为 JavaScript脚本是可操纵DOM元素,在修改这些元素属性同时渲染界面,那么渲染线程前后获得的元素数据就可能不一致了.
在JavaScript引擎运行脚本期间,浏览器渲染线程都是处于挂起状态的,也就是说被”冻结”了.
所以,在脚本中执行对界面进行更新操作,如添加结点,删除结点或改变结点的外观等更新并不会立即体现出来,这些操作将保存在一个队列中,待JavaScript引擎空闲时才有机会渲染出来.
GUI事件触发线程:
JavaScript脚本的执行不影响html元素事件的触发,在t1时间段内,首先是用户点击了一个鼠标键,点击被浏览器事件触发线程捕捉后形成 一个鼠标点击事件,由图可知,对于JavaScript引擎线程来说,这事件是由其它线程异步传到任务队列尾的,由于引擎正在处理t1时的任务,这个鼠标 点击事件正在等待处理.
定时触发线程:
注意这里的浏览器模型定时计数器并不是由JavaScript引擎计数的,因为JavaScript引擎是单线程的,如果处于阻塞线程状态就计不了时,它必须依赖外部来计时并触发定时,所以队列中的定时事件也是异步事件.
由图可知,在这t1的时间段内,继鼠标点击事件触发后,先前已设置的setTimeout定时也到达了,此刻对JavaScript引擎来说,定时触发线程产生了一个异步定时事件并放到任务队列中, 该事件被排到点击事件回调之后,等待处理.
同理, 还是在t1时间段内,接下来某个setInterval定时器也被添加了,由于是间隔定时,在t1段内连续被触发了两次,这两个事件被排到队尾等待处理.
可见,假如时间段t1非常长,远大于setInterval的定时间隔,那么定时触发线程就会源源不断的产生异步定时事件并放到任务队列尾而不管它 们是否已被处理,但一旦t1和最先的定时事件前面的任务已处理完,这些排列中的定时事件就依次不间断的被执行,这是因为,对于JavaScript引擎来 说,在处理队列中的各任务处理方式都是一样的,只是处理的次序不同而已.
t1过后,也就是说当前处理的任务已返回,JavaScript引擎会检查任务队列,发现当前队列非空,就取出t2下面对应的任务执行,其它时间依此类推,由此看来:
如果队列非空,引擎就从队列头取出一个任务,直到该任务处理完,即返回后引擎接着运行下一个任务,在任务没返回前队列中的其它任务是没法被执行的.
相信您现在已经很清楚JavaScript是否可多线程,也了解理解JavaScript定时器运行机制了,下面我们来对一些案例进行分析:
案例1:setTimeout与setInterval
setTimeout(function(){
/* 代码块... */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/*代码块... */
}, 10);
这两段代码看一起效果一样,其实非也,第一段中回调函数内的setTimeout是JavaScript引擎执行后再设置新的setTimeout 定时, 假定上一个回调处理完到下一个回调开始处理为一个时间间隔,理论两个setTimeout回调执行时间间隔>=10ms .第二段自setInterval设置定时后,定时触发线程就会源源不断的每隔十秒产生异步定时事件并放到任务队列尾,理论上两个setInterval 回调执行时间间隔<=10.
案例2:ajax异步请求是否真的异步?
很多同学朋友搞不清楚,既然说JavaScript是单线程运行的,那么XMLHttpRequest在连接后是否真的异步?
其实请求确实是异步的,不过这请求是由浏览器新开一个线程请求(参见上图),当请求的状态变更时,如果先前已设置回调,这异步线程就产生状态变更事件放到 JavaScript引擎的处理队列中等待处理,当任务被处理时,JavaScript引擎始终是单线程运行回调函数,具体点即还是单线程运行 onreadystatechange所设置的函数.
八/080
Linux下Action Script开发环境
鉴于Javascript给我带来的巨大帮助，短短两个月学习时间给我工作带来了很大的进步（包括AJAX应用），最近开始接触接触Action script，看看Flash的东东。
没有那么方便的Adobe开发工具，看看在arch下怎么搞。首先去http://www.adobe.com/go/flex3_sdk下载 Adobe FLEX 3.0 SDK，unzip下就行了。这个东东需要JDK支持，一般都有JRE吧，至少我机器上的freemind需要。。。。
翻了一会AS的PDF，写了点代码试试。
/opt/flex/bin/mxmlc test.as
成功的话就可以看到一个test.swf文件了。用firefox可以打开查看。
目前还没有发现对AS支持比较好的编辑器，geany和gedit以及scribe都不怎么支持高亮，不过scite好像可以。
环境好了，去看语法。