内嵌解析

很容易遇到这样的情况:在需要高亮的代码中还混淆着其它语言种类的代码(最常见的例子为Html内嵌css和js,以下也将以此为例)。这是一件让人头疼的事情,因为无论采用何种方法,内嵌的语言和原本语言的规则一定是不同的。这意味着必须将它们区分开来对待。从这一点出发,自然而然就能引出问题的关键所在——如何区分?

剥离内容

先来考虑最简单的情况:

<head>
<script>var i = 0;</script>
</head>

假如没有第2行的script标签以及其内部的代码,那么整个就是纯html代码高亮,这个没有什么难度(如果已经完全理解前三篇的此法分析的话)。然而不凑巧的是,关键点就在于script标签中会出现js代码,html的此法分析中并没有js的词法规则,两者不能等同。那么怎么办呢?

答案是将它们剥离出来。上例是最简单的例子,我们在对html进行此法分析的时候,一旦读到了<script>开始标签,接着便去寻找</script>结束标签(一般会使用String.indexOf()来查找),然后将标签里面的内容单独提取出来。这是第一步,如果做完的话,此时html的高亮结果应该是:除了js代码没有高亮(即默认颜色)以外,其它的html代码均被正确高亮了。

更复杂的情况

剥离到此还没有结束,因为剥离要考虑其它一些复杂的元素。看以下代码:

<head>
<script>var i = 0;
//</script>
</script>
</head>

代码的第3行中,出现了单行注释,其中有被注释掉的script结束标签。这点需要格外注意。假若使用String.indexOf()来查询script结束标签的话,那么就会在第3行结束。这样就错了,因为第3行实际上是个注释,真正的结束符在第4行。

以此延伸,除了上面的情况以外,引号中的字符串、多行注释、正则里面均会出现类似情况。因此,单纯的String.indexOf()是肯定不行的。我们必须对js代码部分进行预处理。

预处理

在as的解析部分,实际上主要分为两大块:词法分析和存储结果。词法分析即是前面几篇一直在讲解的内容;存储结果即是将分析出来的代码链接起来,说白了就是简单的字符串拼接。

在html中的js代码可能会出现混淆script结束标签的情况之下,唯一解决的办法就是对js也进行简单的词法分析预处理,但不存储结果。因为分析是“读”,而存储是“写”。写的耗时要比读多多了,而且预处理只是为了防止注释、字符串和正则的混淆,不需要真正地进行解析,实现复杂读也比较低。等完全将js代码从html中剥离后,再交给js解析器来做真正的工作,如此也保证了代码的不重复。

<head>
<script>
var i = 0;
//</script>
"</script>"
/*</script>*/
/[</script>]/
</script>
</head>

html中的预处理,至少要保证能将3到7行的js代码完全剥离出来交给js解析器处理,其它html代码则由本身来完成高亮。

状态区分

接下来的难点可能还是在如何在html解析的时候完成区分上面。在这里,我设置了一个state变量用以标识状态。仔细考虑下html,无非发现它主要有以下几种状态:

  1. html节点:即<>内的tag,还有随之的一些属性内容。如:<img width=”100px”/>。
  2. text节点:文本内容,段落p中最常见到。
  3. css节点:style中的css代码。
  4. script节点:script中的js代码。

在默认最开始的时候,是文本节点。一旦遇到了左尖括号,并且随后跟的是个正确的节点名(<x>绝对不是个正确的节点,所以不能当成节点来处理),那么就进入节点状态来解析;当节点解析完了之后,返回文本状态。css和script节点是个两个特殊的节点,因为在它们的开始标签结束之后,要进行预处理查找结束标签。实际上会做其中的一个,另外一个也就懂了。

值得注意的是,html标签中有单个类型的存在,比如<br/>,它不需要成对出现,甚至可以写成<br>。省略/的又是另外一种自闭合类型。它们在处理起来有点麻烦,特别是涉及到深度折叠的时候。解决的办法也是设置状态变量,标识当前节点属于那种类型,以此来区分判断。

这篇写得可能有点简单,因为的确是比较抽象的东西。我也偷偷懒,相信能做到前章所提的词法分析的情况下,纯理论来读本篇也不是什么难事了。可能直接读我的源代码反而会更容易些。在下一篇当中,我会介绍as和js的交互以及jssc的大概处理流程,它将作为结束篇章。

二月 1st, 2010

YY一下各种土豆

2 Comments, 其它, by army8735.

首先还是感谢下小麦,让偶有机会加入土豆大家庭。作为新土豆,来胡乱YY一下假想中的各种土豆吧,我只知道“黑豆”是高清……

  1. 红豆:SNS的代表,红色是社交的颜色,符合这个主题。
  2. 绿豆:健康的代表,绿豆本身就是很有营养价值的豆子,不都说绿色食品么。
  3. 金豆:理财投资的代表,这个没必要解释了吧。
  4. 紫豆:女性专题的代表,貌似粉豆也差不多。
  5. 蓝豆:科技的代表,科技是比较新潮梦幻的,蓝色也是梦幻的。
  6. 黄豆:城市消费?想不出来该是啥……
  7. 魔豆:没想好该是什么……

原文标题:《Functions as Namespaces, and How to Peek Inside》

原文地址:http://www.davidflanagan.com/2009/11/functions-as-na.html

很精彩的技巧,通过闭包和eval()的使用,达到标题中的功能。

var value = (function() {  // Wrapper function creates a local scope or namespace
	// your code goes here
	return value;  // Export a value from the namespace
})();  // Invoke the wrapper function to run your code

以上代码是我们经常用到的技巧:赋值时通过执行一个匿名函数来防止一些代码变量污染全局空间,并且函数内部可以写很复杂的实现而无需担心对外部的影响。

但是有些情况下我们得到的js代码是一串字符串——例如,用xhr读取到的js代码。倘若想要使用它,可以用eval(),还可以用更方便的Function()构造器。

var code = "alert(1);";  // A string of JS code to evaluate
var f = new Function(code);   // Wrap it in a function
f();    // And run the function

//army注:这段代码和下面是完全等同的:
function f() {
	alert(1);
}
f();

所以,通过这种技巧,哪怕是从一段js字符串源代码来赋值,也是可行的:

var code = "return 3;";
var f = new Function(code);
var i = f(); //i是3

但是这里却有一个问题。因为是由Function()构造函数而来的,相当于创造了一个密封的命名空间(所有代码都在一个匿名function内执行),我们无法从外部访问它。倘若里面有一些定义的类或者函数之类的东西,那就难办了。比如这样:

var code = "function Test() {};";
var f = new Function(code);
f();
//这相当于执行了以下方法:
function f() {
	function Test() {
	}
};
f();

内部定义了一个Test类,我们很难访问到它。不过这里有个技巧——这也是本篇要介绍的主角——可以通过闭包+eval()结合使用来绕过这种限制。

var code = "function Test() { alert('a test'); };";
var f = new Function(code + "return function(s) { return eval(s); };")(); //关键!还有后面的括号!
var Test = f("Test");
new Test();

如何?内部的Test类成功从外部创建了。关键就在于第2行,这里有个小小限制,第3行传入的参数需和要使用的内部变量名相等。外部的Test其实相当于密封函数内的Test的一个copy,没想明白的话根据代码倒着走一遍就ok了。

有人好奇JAse中的undo和redo是怎么做的,并且给出自己的设计做法也各有特色。我最初采用的是全文保存方法(这一方法也是最简单有效、使用最广泛的),后来被人痛批一顿换成了命令链。命令链其实是基于一种叫做“命令”的设计模式的,关键思想在于面向接口编程。这个东西随便搜搜有很多例子,我再重复制造一下轮子吧。

AS3中的命令链

as3对OOP的支持已经比较完善,所以可以据此写出很好的命令链,先从简单的例子来说起(以下代码均被简化)。假如我们要做一个Dog类,Dog的“说话”方式是bark(狗叫):

class Dog {
	public function bark():void {
		trace("汪汪!");
	}
}

这很简单,没有什么特殊之处。可是奇怪的事情发生了,中学英语课本中有个闻名的澳洲野狗Dingo,它的叫声和普通的狗不一样:

class Dingo extends Dog {
	public override function bark():void {
		trace("呜呜——");
	}
}

也很简单,Dingo毕竟还是一只狗,只需继承并覆盖即可。好了现在需求来了:我们想听听这些动物的叫声是什么样的,只需要调用下相应的方法即可。

public class Test {
	public function Test():void {
		var dog:Dog = new Dog();
		dog.bark();

		var dingo:Dog = new Dingo();
		dingo.bark();
	}
}

目前为止一切顺利,可惜未来总是不像我们想象的那样。动物中又多了只公鸡,它的叫法完全不一样,是打鸣。

class Cock {
	public function crow():void {
		trace("喔喔——");
	}
}

这下坏了,我们在听叫声的时候得记住,公鸡的叫法和狗不一样:

public class Test {
	public function Test():void {
		var dog:Dog = new Dog();
		dog.bark();

		var dingo:Dog = new Dingo();
		dingo.bark();

		var cock:Cock = new Cock();
		cock.crow();
	}
}

倘若把这些动物排成一列,让它们依次各自叫一下的话就更麻烦了:

public class Test {
	public function Test():void {
		var list:Array = [new Dog(), new Dingo(), new Cock()];
		for (var i:int = 0; i < list.length; i++) {
			var item = list[i];
			if (item is Dog) {
				item.bark();
			}
			else if (item is Cock) {
				item.crow();
			}
		}
	}
}

我们得对每种类型做单独判断,可所谓不胜其烦,动物的种类是不可预知的,倘若再来一只猫,还要继续增加判别吗?当然不能。

显然,关于叫法这里我们需要解耦。不管你是什么动物,这些叫声其实都可以概括为“说话”(动物们也有自己的语言和说话方式)。在主调程序中,我们并不想关心动物是“怎么说话”、“说些什么”的,我们只想调用一个命令,动物对象就能自动按照自己的方式来“说话”,甚至我们不用关心这个动物到底是什么。通过分离做什么和怎么做来实现这个目标的方式,就称为命令模式

好了,首先是命令接口:

public interface Command {
	function say():void;
}

所有动物只要实现了这个接口就行,各自具体的执行方式自己来定:

class Dog implements Commad {
	public function say():void {
		bark();
	}
	protected function bark():void {
		trace("汪汪!");
	}
}

class Dingo extends Dog {
	protected override function bark():void {
		trace("呜呜——"");
	}
}

class Cock implements Commad {
	public function say():void {
		crow();
	}
	private function crow():void {
		trace("喔喔——");
	}
}

这样的话,在主调程序中,管它排成一列的动物有哪些,统统视作Command接口的实现即可:

public class Test {
	public function Test():void {
		var list:Array = [new Dog(), new Dingo(), new Cock()];
		for (var i:int = 0; i < list.length; i++) {
			(list[i] as Command).say();
		}
	}
}

哪怕再多出来一只猫,我们只需要增加猫的这一类别,列表中多出只猫来即可,主调程序无需关心具体实现。甚至猫的方式更加复杂有感情:

class Cat implements Command {
	private var isHappy:Boolean = true;

	public function say():void {
		if (isHappy) {
			purr();
		}
		else {
			mew();
		}
	}

	private function purr():void {
		trace("咕噜……");
	}
	private function mew():void {
		trace("喵——");
	}
}

public class Test {
	public function Test():void {
		var list:Array = [new Dog(), new Dingo(), new Cock(), new Cat()];
		for (var i:int = 0; i < list.length; i++) {
			(list[i] as Command).say();
		}
	}
}

undo、redo的命令链

熟悉了这些后,undo和redo的做法同理:只需实现了命令接口,每个操作各是独自的命令,互不干涉,具体实现自己决定,最大程度上解耦。

定义命令接口(以下代码均被简化):

package command {

	public interface ICommand {
		function redo():void;
		function undo():void;
	}

}

输入命令——也就是在编辑器中敲入代码时:

package command {
	import flash.text.*;

	public class InputCommand implements ICommand {
		private var tf:TextField;
		private var index:int;
		private var text:String;

		public function InputCommand(tf:TextField, index:int, text:String):void {
			this.tf = tf;
			this.index = index;
			this.text = text;
		}

		public function redo():void {
			tf.setSelection(index + text.length, index + text.length);
		}
		public function undo():void {
			tf.replaceText(index, index + text.length, "");
		}
	}
}

删除命令——当按Delete键将编辑器里的内容删除时:

package command {
	import flash.text.*;

	public class DeleteCommand implements ICommand {
		private var tf:TextField;
		private var index:int;
		private var end:int;
		private var text:String;

		public function DeleteCommand(tf:TextField, index:int, end:int, text:String):void {
			this.tf = tf;
			this.index = index;
			this.end = end;
			this.text = text;
		}

		public function redo():void {
			tf.replaceText(index, index + text.length, "");
		}
		public function undo():void {
			tf.replaceText(index, index, text);
		}
	}
}

于是,每当我们输入一个字符时,向一个记录命令步骤的数组里存入一个输入命令;而在按下Delete键时,存入一个删除命令;其它多一个命令多建一个类实现,这样一个链连下来就是命令链

package command {
	import flash.text.*;
	import edit.*;

	public class CommandList {
		private var undoList:Array, redoList:Array;

		public function CommandList():void {
			clear();
		}

		public function addCommand(cmd:ICommand):void {
			//超过最大命令链长度需先出队列一个
			if (undoList.length > Editor.UNDO_SIZE) {
				undoList.shift();
			}
			//每添加一次命令,清空redoList
			if(redoList.length) {
				redoList = new Array();
			}
			undoList.push(cmd);
		}
		public function undo():Boolean {
			//undoList中有命令则执行,并将相应命令出栈存入redoList中
			if(undoList.length) {
				var cmd:ICommand = undoList.pop() as ICommand;
				cmd.undo();
				redoList.push(cmd);
				return true;
			}
			//为空返回false
			else {
				return false;
			}
		}
		public function redo():Boolean {
			//redoList中有命令则执行,并将相应命令出栈存入undoList中
			if (redoList.length) {
				var cmd:ICommand = redoList.pop() as ICommand;
				cmd.redo();
				undoList.push(cmd);
				return true;
			}
			//为空返回false
			else {
				return false;
			}
		}
		public function clear():void {
			undoList = new Array();
			redoList = new Array();
		}
	}

}

其实基于fp10中as3的新特性,有个叫Vector的类,它是存储命令链数组的更好的替代者,因为它规定数组里所有元素的类型必须是相同的。这样在编译期间便能防止出错,于是undoList和redoList更好的定义方式是这样:

undoList = new Vector.<ICommand>();
redoList = new Vector.<ICommand>();

熟悉Java的很容易理解:这就是Java5+中的泛型。

js中的命令链

扯了这么远才到js,而且篇幅也不会多长,真是愧对这标题。

js中并不存在接口,所以也就无从说起面向接口编程。然而以此就下定论说“不能使用命令链”尚为时过早。的确,js由于其本身特性原因,不能像传统OOP语言那样使用,但命令链模式其实就存在于日常生活当中:

function Dog() {
}
Dog.prototype.say = function() {
	this.bark();
}
Dog.prototype.bark = function() {
	alert("汪汪!");
}

function Dingo() {
}
Dingo.prototype = new Dog();
Dingo.prototype.bark = function() {
	alert("呜呜——");
}

function Cock() {
}
Cock.prototype.say = function() {
	this.crow();
}
Cock.prototype.crow = function() {
	alert("喔喔——");
}

function Cat() {
	this.bHappy = true;
}
Cat.prototype.say = function() {
	if(this.bHappy) {
		this.purr();
	}
	else {
		this.mew();
	}
}
Cat.prototype.purr = function() {
	alert("咕噜……");
}
Cat.prototype.mew = function() {
	alert("喵——");
}

var aList = [new Dog(), new Dingo(), new Cock(), new Cat()];
for(var i = 0; i < aList.length; i++) {
	aList[i].say();
}

基于弱类型,每个类都可以拥有一个同名方法,广义上说这也可以看作是实现了一个“通用接口”。js没有编译过程,因此无法在前期(编译期)实现检查,只能靠后期(运行时)来确定。网上也有很多例子模拟出js的接口和命令链,使得一个类在实现接口但却没有实现接口定义的方法时抛出异常。这样做的好处是在运行出错时有详尽的异常信息供使用者检查,但在目前firebug等工具的情况下所提供的能效有限,在大型的开发中才会有很好的帮助。因此我们目前大部分情况下——似乎最好的办法就是相信别人

一月 22nd, 2010

jssc 5.0 beta5

9 Comments, jssc, 前端开发, by army8735.

下载页面:http://code.google.com/p/jssc/downloads/list

源码地址:http://jssc.googlecode.com/svn/trunk/

预览效果:http://army8735.org/wp-content/uploads/jssc/

全部是细节方面的调整。

性能有所略微的提升,体积稍微减少一点,可能整体没啥感觉。因为性能瓶颈主要在两方面:as的分析阶段和js的显示阶段。分析阶段中主要是词法分析阶段和字符串拼接阶段,调整的是词法分析阶段,而这个部分占整体所耗时间不是最多的,所以提升不明显。

接口稍微改了下,具体的看源代码。php由原本的纯php代码变为了内嵌显示方式,像html那样。

这个可能是最后一个beta版了,rc如果放出基本都是针对bug的修补,另外会全面更新wiki的使用方法。

说下5.x系列的计划吧:

  1. 首先是增加语言:诸如jsp、ruby、csharp等等。语系的增加不会增加子版本号,如5.1,而是后缀的小版本号——5.0.1。
  2. 新特性增加将以子版本号形式出现,譬如5.1版本首先考虑的是缓存输出优化(针对代码行上万的高亮显示)。
  3. 也是以前考虑实现而没有实现的特性:自动格式化,这个可能难一点,在以后的计划之内吧。

暂且这么多,有想到新的或者别人的想法再列入计划里。