冰山一角

添加第一个功能按钮 – 在线编辑器(3)

berg — Tue, 29 Dec 2009 21:49:53 +0800

在实现了在网页中插入一个可编辑区域以后，用户已经可以在这个区域中操作富文本内容。但是做为一个真正的编辑器是要有工具栏的，用户能通过工具栏上的按钮方便的对选中的文本进行操作。本文将介绍如何添加编辑器功能按钮。

加粗按钮

首先，我们在页面中添加工具条的HTML代码：

<div id="editor_toolbar">
    <input id="editor_toolbar_bold" type="button" value="B"
style="font-weight:bold;" onclick="editorInstance.bold()" />
</div>

工具条中包含一个按钮，在按钮被按下时，调用editorInstance的bold()方法。期望的结果是：在编辑框内，选中的区域将被加粗。

加粗操作

接下来需要实现加粗功能，在此之前，需要对execCommand()有一定了解

execCommand

execCommand浏览器自带的一个接口，通过它，我们可以对document、selection、或者一个给定的range进行操作。如加粗、斜体等。

语法：

bSuccess = object.execCommand(sCommand [, bUserInterface] [, vValue])
 
sCommand
    String，指定需要执行的命令，如Bold
 
bUserInterface
    Boolean，可选，决定是否显示用户界面，如弹出一个提示框让用户输入，默认为false。
 
vValue
    Variant，可选，一个字符串、数字、或者其他需要assign的值

一般来说，第二个参数会传入false，因为编辑器本身会接管用户界面，第三个参数按照实际需要传入。这样就可以实现对选区的加粗：

document.execCommand("Bold", false, false);

代码实现

只需调用浏览器的execCommand方法，选区就被加粗了。

editor.Editor.prototype.bold = function(){
    this.document.execCommand("Bold",false,false);
};

简单极了！但是总觉得少了什么？是的，没有状态反射。不论用户选中的是否一段加粗的文本，按钮只有一个状态，用户无法感知当前选中文本的状态。

状态反射

添加状态反射的思路是：在选区发生变化的时候，编辑器核心派发一个事件，在此事件发生时判断此时选区的状态，根据状态设置按钮样式。

为何不由编辑器核心直接设置按钮样式呢？这是因为通过事件通讯能最大程度的降低模块和核心之间的耦合，也是模块可插拔的基础。

监听选区变化

造成选区发生变化的根源是鼠标点击或者键盘击键。因此，通过监听onkeydown和onmouseup事件就可以较粗略的得知选区变化。其实，此处将成为编辑器复杂后的第一个性能瓶颈，具体优化办法今后将具体描述。

事件机制

在本示例中，我实现了一个很简单的事件机制，外部模块通过 addEventListener 方法绑定方法到指定的事件，编辑器可以通过 dispatchEvent 方法派发指定的事件。具体代码见文末示例，不再赘述。

queryCommandState

在获得选区变化信息，并且能成功派发事件后，就需要使用浏览器提供的queryCommandState方法来获知选区状态了。

语法：

bDone = object.queryCommandState(sCmdID)

其中的sCmdID是命令标识符，和execCommand接受的第一个参数是相同的。

于是，只需使用：

editor.document.queryCommandState("Bold");

就可以获得当前选区是否处于加粗状态了。

好了，加粗按钮到此就完成了，大家可以看看示例，只在上次示例的基础上新增了60行代码。

浏览器差异

最后不得不提的是浏览器差异。

execCommand和queryCommandState各个浏览器支持的程度相去甚远，ppk大神有一个execCommand浏览器支持程度的详细表格：execCommand Compatibility。正是由于这些浏览器的差异，可能会造成一些在A浏览器下编辑好的内容，在B浏览器下无法修改，或者状态无法反射。

因此，一些成熟的编辑器都会重写这些命令和查询方法，以达到浏览器之间表现一致的目的。做的最好的当属ckeditor

小结

本文完成了加粗按钮，一个按钮一般包括两个部分，设置选区状态，反射选区状态。可以使用浏览器的接口 execCommand 和 queryCommandState 来简单实现。

通过前几篇文章，大家应该对编辑器的基本知识有了一定了解了，下一篇文章开始，我将和大家一起分析编辑器的需求，首先会从功能层面开始。本文是在线编辑器系列文章的第三篇，在这个系列文章中，我会逐步深入和大家分享编辑器开发过程中的奥妙和各种奇怪的问题。如果你对我的文章感兴趣，欢迎订阅我的博客及时收到更新。

得到一个可编辑区域 – 在线编辑器(2)

berg — Fri, 25 Dec 2009 17:57:44 +0800

让一个区域可编辑是实现编辑器最基础的内容之一。

在应用场景中，编辑器的初始状态，要么是从一个空的编辑器（新建文档），要么是从一个已经有内容的编辑器（编辑文档），因此设计这样一个接口：

var editorInstance = editor.create(document.getElementById("editor_source"));
document.getElementById("editor_wrapper").innerHTML = editorInstance.render();

对应的HTML：

<div id="editor_source">
    <h2>在线编辑器</h2>
</div>
<div id="editor_wrapper">
</div>

调用者创建编辑器，然后将编辑器放在自己希望的位置上，这样的实现对调用者的限制最小，而create方法内部，可以通过实例化一个Editor类来实现多例。此时，页面的加载流程是：

调用render()方法返回编辑器的html代码
将html代码插入指定位置
让编辑器的iframe可编辑

render()方法很简单，返回一段拼接好的HTML字符串，供用户插入到任何需要的地方。唯一要做的是在返回之前调用checkIframeAvailable()方法.

checkIframeAvailable()使用setTimeout轮询iframe是否被用户加入到dom中，一旦被加入，通过makeEditable()方法令其中的iframe进入编辑状态。

makeEditable()中，需要对IE和非IE进行分别处理，在IE通过

document.body.contentEditable = true

进入编辑状态，其他w3c标准兼容的浏览器则是

document.designMode = "on"

进入编辑状态之后，还有一些其他的事情要做，为了在firefox和webkit浏览器下和IE通过execCommand()产生的代码尽量一样，需要设置styleWithCSS或者useCSS两个command的值为false。另外，在firefox 2下，在创建iframe后，无法立即读取editor.document.body，需要使用setTimeout在下一个时间片读取。

这样，通过寥寥几十行代码，一个最基础的编辑器框就完成了，请看最终示例。你可以从外面粘贴一些带有格式的文本进入编辑器看看效果。

本文是在线编辑器系列文章的第二篇，在这个系列文章中，我会逐步深入和大家分享编辑器开发过程中的奥妙和各种奇怪的问题。下一篇文章将介绍如何给编辑器添加按钮操作，如果你对我的文章感兴趣，欢迎从页面右边订阅我的博客及时收到更新。

历史、现状和目标 – 在线编辑器(1)

berg — Wed, 23 Dec 2009 08:10:07 +0800

关于本系列文章

计划暂时是这样，首先介绍一些历史、知识背景，然后详细分析现状和需求，开始设计一个可扩展，低耦合的编辑器，最后针对一些难点问题进行单个分析。

历史、现状

起初，世界上的浏览器本没有编辑器功能。到了IE4.0 (1997年)，微软提供了document.selection，利用这个对象，前端开发人员可以让一个iframe进入编辑状态，里面可以输入富文本内容，并且能通过程序添加复杂的编辑操作。那个时候还没有W3C的相关规范，这个selection对象以及两种选区类型（textRange和controlRange）都是微软自己实现的。

三年后，有了W3C的相关规范(2000年)，这个规范和IE的实现完全不同，firefox等一干浏览器陆续根据规范实现了自己的selection和Range对象。

前端工程师的悲剧就这样酿成了，有两套截然不同的方式来处理选区(selection)，不仅仅如此，对execCommand()方法的支持也大相径庭，一个相同的命令在不同的浏览器下执行会出现不同的效果。最要命的，浏览器还经常会有一些诡异的问题，比如在某些时候对选区的不当操作会导致IE直接崩溃等。

但是在线编辑器的使用场景相当广泛：写blog、论坛发帖、淘宝卖东西、在线聊天等应用场景都需要使用编辑器，他们对编辑器的要求各不相同。编辑器已经成为了一个基础件，几乎所有的互联网公司都需要用到。

后来出现了一些开源编辑器，比较出名的有：ckeditor（原来叫fckeditor）， tinymce，eWebEditor等，最近，淘宝也开源了他们的kissy编辑器（功能尚不完善）。但是开源编辑器都各有不足，ckeditor足够强大，重写了浏览器的所有操作。但是模块之间的耦合性很高（3.0有所改善，但仍然不够），体积过于庞大，其他的一些编辑器则要么bug太多，功能不全，要么不方便二次开发。另外，一些对编辑器要求很高的服务，像zoho、Google docs等等，都带有一个很强大的编辑器。

目标

一个优秀的编辑器，首先要尽量解决浏览器之间的差异，在不同的浏览器下表现一致。

另外，为了让编辑器在各种不同环境下适应不同的需求，尤其是二次开发的需求，这个编辑器还应该是“通用”、“可扩展”、“低耦合”的。

具体的设计思路在后面我会专门撰文说明，首先的这几篇文章，是让一些没有接触过编辑器开发的童鞋了解一些基础知识。

本文是在线编辑器系列文章的第一篇，在这个系列文章中，我会逐步深入和大家分享编辑器开发过程中的奥妙和各种奇怪的问题。下一篇文章将介绍如何拥有一个可编辑区域，如果你对我的文章感兴趣，欢迎从页面右边订阅我的博客及时收到更新。

善用分布式版本管理系统管理个人代码

berg — Sun, 13 Dec 2009 23:03:37 +0800

大多数人都知道或者善用多种版本管理系统，传统集中式版本管理系统有CVS、SVN等，后来，出现了一些分布式管理系统，如GIT、mercurial等。几乎所有有开发工作的公司，都会选择一个版本管理系统，并且制定一些规范来管理代码，道理很简单，使用版本管理系统能在多人开发，跟进bug，追查问题方面减少很多管理和沟通的成本。

但是，我觉得个人的代码，包括一些软件配置文件，完全可以使用分布式版本管理系统来管理，可以让我们减轻很多麻烦。

使用传统的集中式版本控制软件来管理，好处如下：

不用担心因为无意的错误修改，删除而丢失过去的代码
可以随时查看历史情况，你就不用为“xx功能、yy修改到底是什么时候加进来的，为什么要加”这类事情而挠破头皮了
可以进行分支开发，比如说一个功能你不是很确定能否实现，拉一个分支开发就是了

更进一步，使用分布式的版本控制还有如下好处：

在本地就有版本仓库，你可以在任何时候进行ci和roolback，无需联网
超级快速的分支切换
方便的和他人（其他机器）共享代码，一个push，或者pull，就能快速的同步修改

下面我举几个例子来让大家感受一下善用分布式版本管理的好处。

保证多台机器上的配置文件统一

我们有很多很多配置文件，尤其是linux下。vim配置，apache站点设置，桌面的配置，pidgin的账号设置等等。
但是如果有多台计算机，如果两台机器上配置不统一，用起来不顺手，更可能会带来麻烦，我们需要找到这些配置文件，并且拷贝一份最新的到当前机器，但是如果两边都有修改，就可能会丢失修改，或者需要手动merge。
过去可能用人使用过rsync来同步文件，能解决部分问题，但是如果使用分布式版本管理系统，在每台机器上都有一个独立的代码仓库，用这来管理配置文件再方便不过了！

首先，我们现在一台拥有最新版本配置文件的机器上初始化一个版本库

cd ~/
hg init
hg add .vimrc .screenrc .fvwm #添加所有你关注的配置文件

然后，一旦有新机器需要使用这个配置，clone一份即可

cd ~/
hg clone ssh://berg@lastPC://home/berg/
hg up

如果在任何一台机器上有修改，只需要ci到当前机器，并且到其他机器上pull这份修改。

hg ci
ssh berg@anotherPC://home/berg/

我们不需要关心代码的合并，也不需要关心配置文件的具体名称和位置（在linux下面，所有的配置都是隐藏文件），一切细节都交给mercurial来管理。

使用中心服务器

分布式管理原则上是没有一个强制的中心服务器，但是如果我们在管理的规则中加上中心服务器，在某些时候就能避免一些尴尬的发生。

举一个例子，假设我有三个开发环境，一台在公司，一台在家里，还有一台服务器。在公司时，我家里的机器是离线的，在家里则反过来。于是我白天在公司开发完毕后，想在家里获得最新的版本，最简单的办法就是在服务器上架设一个中心版本库，下班时，push代码到服务器上，回家就可以直接pull了。

使用中心服务器可以避免在需要开发时，发现最新版本所在计算机不在身边，并且处于离线状态的尴尬。

灵活的分支开发

不要以为分支功能在小项目中就毫无用处，有的时候，善用分支可以减少很多麻烦。而集中的版本控制系统处理分支很麻烦，让人避退三舍，可是到了分布式版本控制这里，分支变得很简单，看看下面的例子。

我在开发一个项目时，遇到了一个较大的修改，涉及面较广。
如果直接在主干上开发，如果在开发过程中发现了bug，或者其他临时插入的想法，我有两种选择：

直接在线上修改，或者重新clone一份到本地的其他目录进行开发
把“projectA”这个项目做为一个分支在本地开发

两种好处的优劣是很明显的，第一种，我要么需要冒线上修改的风险，要么需要在本地配置另外一套环境；而第二种，我只需要在碰到其他问题的时候，将分支切换回去就好了。下面是命令示例：

首先，将本地仓库的当前branch设置成项目A的名称：projectA

hg branch projectA

我进行projectA分支的开发，如果在开发的过程中，我需要切换到原来的分支：

hg ci -m "projectA commit"
 
hg up default #切换到主干

开发完毕后提交并且push到线上：

hg ci -m "modified something"
 
hg push

接下来我又能迅速的切换回原来开发到原来开发到一半的uploadify分支

hg up projectA

分布式版本管理的好处一下就体现出来了，我可以在本地迅速的切换分支，分支建立的成本也很低。这样能让我们更灵活的应对需求

小结

好了，本文就写到这里。小结一下，使用分布式版本管理系统管理个人mini项目、软件配置文件，能给开发和管理带来很大的便利，使用中心版本仓库能避免机器离线导致无法获取最新代码的问题，善用分支能让开发者更灵活的应对需求。

看了本文后，是否你对分布式管理系统也充满了兴趣呢？或者你有一些更好的实践？欢迎在下面留言共同探讨。

在javascript编程中灵活使用try-catch

berg — Sat, 05 Dec 2009 20:40:31 +0800

上周，在分享家的qq交流群里，经常有人向我反馈不能下载东西。于是直接联系了一个用户，发现他的浏览器报出pageTracker对象不存在错误。

问题很显然了，由于我在下载链接的onmousedown事件中添加了Event统计，如果用户的Google Analytics代码没有加载成功（显然是万恶的教育网造成的），那么就会报出这样错误。

请看原来的代码片段：

function analytics(category, action, label, value){
 
    pageTracker._trackEvent(category, action, label, value);
 
}

修改一下，加上try-catch屏蔽这个错误：

function analytics(category, action, label, value){
 
    try{
 
        pageTracker._trackEvent(category, action, label, value);
 
    }catch(e){}
 
}

用try-catch来屏蔽浏览器错误是一个Javascript编程中很常用的一个技巧，灵活使用可以给开发者减少很多麻烦，下面再举一例。

最近，我在开发一个通用的所见即所得编辑器。某些时候，程序需要记录住当前状态的节点，给后续程序处理。但麻烦来了，用户如果持续的在进行编辑动作，在程序后续处理时，节点可能已经不在DOM树中了。

在IE下，如果你调用一个不存在的文本节点(nodeType == 3)的任何属性或者方法，浏览器直接报错。根本找不到能判断这个节点是否存于DOM树中的方法。于是有了如下代码：

try{
 
    if(ele.ownerDocument != editor.document)
        return false;
}catch(e){
    return false;
}

上面的代码很好懂，首先判断这个节点是不是在编辑器中，如果不是，返回false；如果在过程中出现了错误，也返回false。

关于try-catch的故事就说到这里，最后要提醒大家，try-cacth会影响javascript的性功能，因此不应该在追求性能的环境中使用，尤其是一些基础方法或者会被多次调用的方法中。
下一篇文章，我将使用一个更好的办法来解决文首提到的Google Analytics报错的问题。欢迎你订阅我的博客，在第一时间获得更新。

化解内心的冲突

berg — Sat, 07 Nov 2009 14:09:11 +0800

昨天晚上和今天早上，看完了这本书(《化解内心的冲突》)的前两大章，这是一本讲述如何化解与他人之间冲突的书，在阅读这种书之前，或多或少总会有这样的心理：如果我让步了，岂不是总是吃亏，让别人占便宜？看时才觉得，谁能更早获得内心的平和，谁就是成功者，不管问题是不是按照预想的方式去解决的。

这本书和“谁会认错”的核心思想一样：放弃自我辩解。但是他们阐述问题的角度不一样，《谁会认错》是从一些历史事件开始，从内心出发，层层剖析为什么人会自我辩护，然后给出方法，让我们摆脱自我辩护的漩涡。而《化解内心的冲突》是从人与人之间的关系出发，我们之所以陷入自我辩护，是因为我们不把其他人当作一个平等的个体来看待，而是把他们当做物体来看，并且自己在内心中形成了“战争”状态。我更喜欢后者的这种阐述方法。从人与人之间的、平常经常在自己身上发生的小事出发来说明问题，比从一些历史事件更容易让我感同身受。

我们不能把其他人当做物体来看，即使我们的观点是“正确”的，但是如果冲突双方都相信自己没有错，冲突就无法解决。即使，在立场，行为等等表层上面我们是“正确”的，但是从对待他人的存在方式上来看，内心处于战争状态就是错的。我们要有平和的心态，站在对方的角度来看待冲突，化解了内心的冲突，才能化解与他人之间的冲突。

我们是怎么进入“战争”状态的呢，“战争”是和“平和”对应的，当我们处于战争状态时，这种情绪就会破坏我们的感觉和对待他人的态度。当和他人产生冲突时，如果心中已经处于战争状态了，不管外表是否平和，内心的冲突会让我们还是会引入其他的问题，始终无法真正的化解矛盾。

如果两个人都处于“战争”状态，就会逐步主动的将冲突升级：当一方想到对方对自己的不平以后，会变本加厉的对对方不平，反过来，对方也会这样做。

很多时候，我们一开始是有帮助他人的想法的，但是一旦抛弃了这个想法，内心进入了战争的盒子以后，就会产生一种新的需要，需要证明自己的战争状态是对的，于是对其他人的观点就会更加歪曲。

有的时候，我们的确受到了不公正的待遇，但是，只有在自己需要为自己的行为进行辩解时，才会纠缠于这些受到过的苦难，在那一刻，这些苦难其实就是借口。

有时，我们会觉得自己高人一等，觉得自己被赋予了很多“特权”，当自己处于战争状态时，就会认为这些特权消失了，所以更加心怀怨恨，而实际上，这些特权从未存在过。就像在职场中，我们会觉得自己很聪明，应该在职位上获得更快的晋升，但是一旦没有获得更快的晋升时，我们就会怨恨，为什么上级没有给我们这样的待遇，不是我错了，一定是他们错了。实际上，我们并不比其他人更聪明。

我们经常处在“自我背叛”中，我们违背了自己对他人原本的感受，导致我们以不同的眼光看待别人、自己。比如说，当饭后，丈夫想帮助妻子清理厨房时，但赖在沙发上不动，本来应该感到内疚，但是却背叛了自己的感受，为自己无动于衷的行为产生辩解，“我忙了一天了，为什么还要我做这些事情”，“她经常对我发号施令，我才不听她的”。这样就把自己放在了战争的盒子中，以后每次遇到这样的事情，就会积聚起来，让内心的冲突升级。

书中一些重要观点：

和我们打交道的都是独立的个体，他们并不总是按照我们喜欢的方式行事
损人不利己是一个不明智的选择，但我们还是会这样做。而很多时候，我们几乎是觉得是收到某种力量的驱使，不得不这样做
我们作出回应的依据是对方对我们的态度，而不是行为本身。因此，如果我们心中敌对的面对他人，他人并不因为我们“平等”对待他们的行为而作出善意的回应
四种自我辩解模式：“高人一等”，“我就应该”，“需要被看做”，“怨天尤人”
我们不仅仅要为自己所做的负责，也要为自己所想、所感的负责

http://www.douban.com/subject/3312040/

假期结束志

berg — Fri, 09 Oct 2009 01:08:10 +0800

假期悄然结束了。

举世瞩目的60岁生日顺利结束，也让我更加切身感受到了这个国家和政党的繁荣昌盛，以及做为屁民的我暂住在伟大首都的悲哀：道路封锁，到处盘查身份证，出租车上安装窃听器，安检超级麻烦，Google android手机无法同步Google账户，大量网站包括https网站被封，blah blah。

Google wave开始邀请，我现在开始有点后悔没有去2009 Google 开发者日了，因为据Zealot说，参与者都能得到一个Google wave的邀请名额，但是感谢好心的catChen，他在前几天给我提名了，但是我至今没有收到任何邀请。至于Google wave本身，视频很炫，但是据几位切身使用过的人来说，目前实用价值并不大。

假期去看了风声，一部在北京宣传的相当到位的片儿，三星半推荐吧，本来应该是4星，但是故事情节太多瑕疵，在看电影的时候我已经尽力去忽略它们，但是却让人回味起来的时候兴趣索然。而且事先提醒，这里面e镜头太多，口味轻的MM不推荐。其他的介绍，看宣传片和介绍吧，不过，今天在四号线里面看到的宣传片，段奕宏、朱旭，和外景本身没有几分钟戏，却在宣传片里占了过多的分量，如果是看了这个宣传片而去的影院，一定会有被骗的感觉。

博客小小做了一些调整，原来每周定时程序发布的那些Google Reader shared items被全部删除，因为在之前（连接），Google Reader的社会化改进上线后，用户可以像Twitter一样Follow其他人的Google Reader；同时我觉得那些自动输出的文章会让人很不快。因此，如果关注我Google Reader的Shared items的话，可以通过这个页面Follow我。

睡觉去，明天上班。

wordcamp 2009

berg — Fri, 21 Aug 2009 20:53:44 +0800

明天是8.22，也就是wordcamp 2009 china的活动日了啰。

最近俗事缠身，开始了一个新的项目，经常加班才能勉强忙完，前段时间服务器所在的机房破产，不但让我产生了经济上的损失，还浪费我一个周末去了一趟江苏，而且是坐大巴回来的，那叫一个痛苦。最后机器迁移到了传说中世纪互联的酒仙桥机房。

这个周末算是清闲，准备明天去wordcamp，看看各位传说中的风云人物；后天去骑车，路线基本确定为白羊沟。

生活的改变

berg — Mon, 20 Jul 2009 17:54:52 +0800

自从我买了自行车，开始骑行以后，生活就逐步的改变了。不只是骑行这么简单，而是生活方式和思想，也不是因为骑行，骑行只是一个契机而已。

首先，我不宅了。从周末至少有一天出门骑行开始，到现在已经持续若干周周末两天不碰电脑。虽然最近两周周末都没有出市内骑，前天我的总骑行里程还是超过了1000km。

然后，我开始关注一些非电子的东西，我买了一支钢笔（lamy safari），加上之前的若干本子，我开始经常用笔写一些东西。

还有呢，最近开始玩桌游，三国杀当然玩过了，第二站是卡坦岛。

fancy和dzy已经来北京了，一些新的事情又将开始。

offsetwidth、clientWidth、scrollWidth的区别

berg — Fri, 19 Jun 2009 12:47:11 +0800

最近在写一个拖拽模块，支持range，也就是说一个element只能在一个固定的范围内拖动。于是我需要知道当前被拖动的element的大小。

最初我使用scrollWidth，发现在ie6下，如果这个element有border，就会有偏差，后来经过erik的建议使用offsetWidth解决。

上网查了一下，得到如下答案：

scrollWidth是对象的实际内容的宽，不包边线宽度，会随对象中内容的多少改变（内容多了可能会改变对象的实际宽度）。
clientWidth是对象可见的宽度，不包滚动条等边线，会随窗口的显示大小改变。
offsetWidth是对象的可见宽度，包滚动条等边线，会随窗口的显示大小改变。

这篇日志是每日一web-dev tip计划的一部分，如果你关注web开发或者linux，请订阅我的rss。