2010-10-21 updates: 根据Wait在评论中提出的对于初始化以及触发事件等的扩展，改写了一下代码。当初是注重了功能完好的实现，没有在意后期的扩展和维护，这两方面得结合起来思考。对此，先不说代码编写以及接口提供的好与否。当然了，因为这个相当于是一个模块，就涉及到独立的HTML，JS，CSS等，特别是CSS可能就需要使用JS脚本来动态插入到页面中，这个先不提供，先从简单的开始吧。一切源于简单，也终于简单，过程会很负责…… 下面还是使用给每一个li添加事件的方式，而并没有使用事件委托的方式，当然了，改成事件委托，也都还是可以，不过也得使用循环来初始化。 [javascript] init: function(props){ //使用对象字面量的方式作为参数 props = props || { "id":null, //handler id "trigger":"click" //事件类型 } if(!props.id){ … 了解更多
今天在看博客的时候，萌生了这样的一种想法，目前博客更新不是很快，那么相对来说，很多内容都是在一定时间内保持不变的，那么就相当于是一个静态的内容，既然是相对静态的内容，那么每次访问的时候还从服务器的MySql数据库读取相同的内容，这就造成了一定的服务器端资源的浪费，如果可以将这些相对静态的内容使用客户端存储技术在本地存储起来，在单个用户再次访问的时候，直接从本地存储中读取静态的内容，而无需从服务端读取内容，那么页面的初始化将会是更加的快速，另一方面也可以最大化的节省流量。
发布-订阅模式也叫观察者模式，说的简单点就是信息的发布者只管发布信息，信息的订阅者可以订阅多个信息发布者的信息，而两者之间都可以不管彼此是谁发布和谁订阅，而通过一个信息管理器来处理两者之间的订阅/发布逻辑。一个订阅者可以订阅多个信息源，一个信息源也可以被多个订阅者订阅，所以是一种多对多的关系。 但是在设计代码模式之前，有几点是比较困惑的：首先，对这个模式具体的实施方式还不甚了解，只懂得个大概的理念；一个发布者对多个订阅者这个怎么来处理；发布者、订阅者、消息管理器如何设计；发布者怎样发布、订阅者怎样订阅才更加的符合发布/订阅的这个理念；储存多个信息源。从这几点出发，先进行了下面的尝试：