Mar 4th, 2010
by Fan Fan.
有时候web页面会包含一些隐藏数据，或者”非显示”(non-visible)数据。比如Google Reader中的博客文章列表：
这里很多的Ajax操作都需要文章的唯一id，而这个id是没有显示在页面的。这种情况应该很常见。
老的方法可能是用类似<a onclick=”process(’243242′);”/>这种方法，不过现在很少用了。这把control逻辑和显示混合到一起了，元素少的时候还不明显，元素多了会有很多的process(’xxxx’)这样的重复逻辑。（我后来发现jquery binding的时候就可以传递数据，sigh，也算是一种方法吧。）
一般在HTML中嵌入数据的方法为利用HTML Element的class或者attribute。
利用class的例子为：
<div class=”entry entry-2″/>
<div class=”entry entry-3″/>
利用attribute的例子为：
<div value=”10″ maximum=”100″ minimum=”0″/>
这里面maximun和minimun都是非标准的属性。
当然也可以使用hidden的element来持有数据，这些方法的缺点在于把数据嵌入到显示中来，导致页面混乱。再者这些非标准的方法使页面丧失语义性，这里详细的讨论了这个问题。HTML5中有一节Embedding custom non-visible data改进了这个问题，这样写：
<div data-ship-id=”92432″
data-weapons=”laser 2″ data-shields=”50%”
data-x=”30″ data-y=”10″ data-z=”90″>
个人感觉也其实也很难看，谈不上优雅，比XML差不少。或许HTML本来其实不适合做这种事情，语义网也许是解决的根本之道，唔，扯远了。
这种嵌入数据的需求在Ajax流行下越显突出。web2.0提倡的所有操作在一个页面完成，这样最后页面会很复杂，需要承载更多的数据。
如果从server端返回HTML，这些HTML数据的较之XML和json就复杂多了，因为这样的HTML是数据和显示的混合。特别是在像表格这样的数据比较集中的地方，HTML这种格式不适合javascript对其进行数据的后期处理。（只有在表格这样的地方，这个问题才比较突出）
使用json后，页面的rending又成了一个问题。一般可以用json templete来处理，比如json-template。这样数据是独立出来了，view也独立出来了，不足的地方是缺少一个binding的机制，否则在数据和view间的每次操作都得手工建立对应关系。
Dojo里面的dijit/widget对于这种情况给出了很好的解决方案。widget作为一个对象或者组件，数据可以直接用类似成员变量保存在对象中，不用很怪异的把它嵌入到html中，然后取值又得费劲的操作DOM。
使用组件的概念后，OOP的优点也继承到javascript中来。组件消除了全局变量，对HTML页面进行了隔离，这样规范后就不会出现原来的document.getElementById满天飞的操作。由于不是在总的document之下，一个组件的定义中就不能假设另外的组件的存在，这样，组件之间通过event来耦合，这比getElementById来直接访问是一个很大的进步。
Feb 9th, 2010
by Fan Fan.
用Rails开发煮豆（zudou.net）这个小应用有段时间了，对于一个从Java转过来的人说，变化还是很大的。
总的来说，Java一般偏向企业应用，而Rails偏向互联网应用，两者开发思路很不同。Java用来处理数据或者后台应用比较多，而互联网处理页面更多点，用到很多Ajax和HTML来对界面精雕细琢。企业应用的用户需求是固定的、文档化的，而互联网则开放很多。
从技术上来说，Rails语言很轻巧，上手很快，刚开始会觉得原来的Java开发效率实在是太低了，但是如何有效的调试程序则是个大问题，遇到程序异常很容易束手无策，具体原因一则新手对架构内部和语言细节不熟悉，二则不同平台有不同调试方法，这方面经验是跟平台绑定的，不能共享的，不同的平台的常见异常都不一样，Java下容易出现Nullpointer，Rails则千奇百怪。从另一个方面说，Java语法更严格，文档也很多，所以虽然开发效率低，但是按部就班，也不会很慢。
而对于一个框架开发者来说，调试也要纳入到易用性中来，错误信息要充分，简单而且明了，很多错误信息读起来不知所谓，对于一个满头是包的人来说，拿着这些仅有的救命稻草，如果没有多少信息该是多么有挫折感。
Aug 5th, 2009
by Fan Fan.
网易新闻办的还不错，不过受不了他的页面字体，真是难看，还是hard coding成“宋体”，真是莫名其妙。下面代码很简单，直接修改字体。不过这个script有个缺点：页面在全部装载完后才改变字体，由于163加载比较慢，所以可以看到字体刚开始是宋体，最后才改为雅黑。怎么样在装载前就修改CSS呢？照这里的帖子看来，Greasemonky是无法实现的。
// ==UserScript==
// @name 163beauty
// @namespace fkpwolf.net
// @description modify the face of 163.com
// @include http://*.163.com/
// ==/UserScript==
document.body.style.fontFamily=”serif”;
Jul 11th, 2009
by Fan Fan.
最近在一个项目中用到了Portlet，总结下使用的感受。
1）页面的重用，类似于“多窗口应用程序”，对于一些复杂的业务，用户可能要在操作间做些参考，比如查看账单的时候显示客户的详细信息，我们可以在两个不同的“页面块”中显示：一个显示账单信息，一个显示用户信息，否则用户就要打开两个浏览器窗口。这种场景越多，越能显示Porlet的威力。
2）页面的交互。页面细分后这个就成了一个突出的问题，如何在Portlet间传递消息比一般的JSP更加复杂。只有解决这个问题才能达到页面级的重用，而这比一般的代码级的重用难多了。在Jboss Portal 的Feature List里面可以看到其提及IPC：Inter-Portlet Communication API来专门的管理Portlet间的通信。Version 2.0的Portlet规范JSR 286已经出台，其中有一章”Coordination between portlets” 。在IBM DW上有一个系列：JSR 286 Portlet 的新特性。IBM的实现中有个“cooperative portlet”的feature，提供了一个声明式的界面来组织Portlet间的契约，使用Observer的模式来定义消息的订阅者和发送者，这些契约是运行时的，较之写入代码中的方式有更好的后期维护性。而这个强大的功能有一个很大的局限性：消息是同步的，比如消息就很难在Page间进行传递，这对于一些复杂的场景下是致命的。同时这也对Portlet的布局有了更高的要求，尽量的，相关联的Portlet一个放在同一个Page中。
More about IPC, please visit here, there are a lot of useful links.
3）Session的单独管理：每个portlet都有自己独立的session，这减小了session的生存范围，较之一般的HTTPSession更容易管理。
5) 开源的Portlet产品有Apache的JetSpeed，IBM的IBM Portlet开发模式就是基于这个开源框架的。还有个叫“Liferay Portal”的产品，好像还是很流行的，有很多特征，比如加入了Social Networking的元素。如其名字，其不仅是Portlet，而是一个Portal容器。
5）适用于在定制化程度需要很高的地方，比如网站的门户首页。一些SNS站点如Facebook更需要类似的功能。后者像一个大而全的聚合器（或者粘合剂），将各方面的信息收集到一个位置，而这也是社会化站点的特征。
6）开发模式较之原有模式，局限性很多，这主要是由portlet container决定的，由于页面的随意性，也造成了测试的难度加大。而如果想用一些已有的技术比如JSF作为展示层的替代，则需要一个定制的中间层使JSF接入到Portlet容器中。
