首先是这一版加入的几个新的 Widget: Clock, FilteringTable,ProgressBar。这些widget中比较重要的是 FilteringTable， FilteringTable的加入是用来替换以前的SortableTable，相比SortableTable, 它的新的特性包括：

Multiple Column Sorting (number of columns settable, default is 1)
Sorting in place (non-destructive)
Per-column programmatic filtering
Add and remove rows on the fly
Update field values (with typing) on the fly
No restrictions on sorting on markup

    从这个地址去体验一下： http://archive.dojotoolkit.org/nightly/tests/widget/test_FilteringTable.html，功能非常强大，可以直接从传过来的JSON对象中构造出列表，动态的过滤数据，改变各个字段的值，可惜这个版本中还不支持分页，列、行的拖拉的功能，只能是期待下一版了。其他几个Widget也都非常的实用，dojo的官方网站上都有例子，感兴趣的可以去找找。

    下一个是让人感到惊喜是新增的 dojo.charting 和 dojo.gfx 包， dojo.charting 提供了一个基于Vector实现了多种图表类型的charting engine，从demo上来看，非常不错哦！ 可以从这个地址体验一下：

 http://archive.dojotoolkit.org/nightly/tests/charting/test_engine.html

   另外一个好消息是，从昨天dojo官方网站的新闻上看到 Greenplum 和 SitePen（两个技术型的企业） 宣布把他们的一些技术捐赠给Dojo的 new charting engine。dojo.gfx是一个二维矢量图形的API，能自动的根据客户浏览器的类型决定使用SVG或是VML，也很实用，比如新增加的Clock Widget就是基于这个包实现的。这两个包的加入让我们有理由相信不远的将来，dojo必然会撑起网页图表的一片天!

    然后是 dojo.a11y 包，a11y 是accessibility的缩写，主要是加入对键盘按键（快捷键）的支持。官方网站上说的是在Dojo 0.4中只有一部分widget中已经加入了这方面的支持，在0.5中会加入努力更多。

    国际化支持方面，这个版本的 dojo.i18n 包做了不少的改动，加入了对 collecting localized resources 的支持，提供了更多的date and time 的格式，此外对很多 widget （DatePicker, TimePicker等等） 也做了国际化的改进，不过DatePicker，TimePicker依然是丑陋无比。可以看到和dojo 0.3.1比，国际化的框架并没有很大的变动， 这次主要是具体的进行一些完善。

    还有很多其他的包，像 dojo.lfx，dojo.namespaces，dojo.html等等，在这一版中也都得到了很大的提高，详细一点的列表可以查看 http://dojo.jot.com/WikiHome/Release0Point4 。

    从0.3.1 到 0.4 几个月的时间里dojo便得到如此大的提高，根据Dojo网站上的公告，dojo 0.4.1过几天也就要发布了，在几个月后又要出0.5，按照这效率，想想一年后的dojo，真是让人抓狂！

  function checkEmail(email)
  {
        if (email.length == 0 )
            return true;
         var validEmail = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;
         if (validEmail.test(email))
         {
                 return true
          }
           return false
    }

    checkEmail("123456789012345678901234567890123456789012345abcdefghijkl");

   第一反应是正则表达式写的有问题，'@'前后的 ([\.-]?\w+)* 都可能会引起效率问题。下面仔细分析一下:

1. 从输入的值来看， engine会首先匹配 \w+， 这是一个贪婪匹配，可以一直匹配到结尾；
2. 然后按优先级开始匹配 ([\.-]?\w+)*中的 [\.-]?\w+，这个时候前面的 \w+ 为了后面的匹配成功，必须要重现匹配，让出一点匹配的内容，假设先让出的是 'l'，([\.-]?\w+)*匹配成功；
3. ([\.-]?\w+)* 意味着要尽量去匹配多次，再第二次对 [\.-]?\w+ 匹配，这个时候为了第二次匹配的成功，第一次匹配的 [\.-]?\w+ 要让出能满足第二次 [\.-]?\w+ 的内容，也就是它匹配到的'l'，这个时候，第一次匹配的 [\.-]?\w+ 又不满足了，\w+ 又得让出来一个'k'。
4. 这样未知匹配次数的 ([\.-]?\w+)* 就形成了一个很大的循环，而在正则表达式中，每次匹配时被括号里模式匹配的东西都是要被存起来供以后使用的，大量的中间结果被缓存，最终导致IE死掉。

   所以这是一条典型的因为循环尝试匹配导致效率低下的正则表达式， 表达式中两个 ([\.-]?\w+)* 都可能导致解释器的crash，在本例中不需要利用匹配的中间结果，所以解决的办法很简单，在括号加入一个冒号，不保存中间结果就是了。即将那个正则表达式改成如下：

  /^\w+(?:[\.-]?\w+)*@\w+(?:[\.-]?\w+)*(\.\w{2,3})+$/

如果性能还是不能满足需求，可以考虑把这个正则表达式拆成几个小的表达式，分别进行验证。

有人曾经在他的一篇blog[ http://blog.cathayan.org/archive/1/2005-7-4 ]里非常形象的介绍过 GB18030 的历史,转贴精彩部分如下：

1，GB2312是很老的东西了，早就发现不够用了。
2，94年（还是之前）国家推出了建议性标准gb18000（还是13000我忘了），这个标准其实就是utf-8标准（除了名字，完全一样），同时也建议微软公司采纳。－－（据说是1993年，GB13000，应该是ISO10646）
3，微软借口说gb18000还不成熟，为了取得中国市场的垄断地位，自己搞了一套汉字标准，于是它就随着win95和office之类的流行起来了，国家看生米已经煮成了熟饭，只好把这套标准定为国标GBK标准。－－（其实只是指导性标准，并非强制性，GB18030是强制性标准）
4，微软到了99年（前后吧），又说GBK已经落伍了，现在流行utf-8标准，准备全盘转换成utf-8，这些把有关部门惹怒了。NND，当年我们推utf-8你说不成熟，自己搞了一套，现在赚得盆满钵满了又自己说要推utf-8了，你丫微软分明就没把政府放在眼里。
5，于是政府怒了，强制推行gb18030标准（这个标准前面兼容GBK，其他码位兼容utf-8），算是过渡标准吧。要求微软强制执行，否则产品不得在大陆买。于是基本搞死了微软的WindowsMe，差点搞死了Office2000（据说发行前几个月，微软除了改字符编码就没干其他什么事情）－－（确实，WinMe是我认为的最差的Windows版本，而office2k也是前不着村，后不着店，前后兼容性都差）
6，由于以上历史原因，现在就是GB2312，GBK，GB18030，UTF-8并存了。
7，如果不是万恶的微软，我们早就用上UTF-8了。

   或许正是因为微软和中国之间为GB18030发生了这么多的恩恩怨怨和当年微软的仓促上阵，直到现在微软的很多产品对GB18030支持的依然不是很好。访问下面的页面，了解MS对GB18030支持情况及下载Windows下的GB18030安装包：

http://www.microsoft.com/globaldev/DrIntl/columns/015/default.mspx

虽然MS声明在Windows XP 和 Windows 2000 中通过"add-on"来支持GB18030，但是IE 6.0直接显示 List Box、Drop Down Menu、Text Area、Text Field中的GB18030字符依然还是有问题，下面的这篇文章有相关的介绍：

http://www-306.ibm.com/software/globalization/gb18030support/retrieve.jsp

在IBM的这篇名为"Globalize your On Demand Business"的文章里，给出的solution是在要显示GB18030的元素上加上类似 "STYLE="font-family:'SimSun-18030'"的CSS声明。在当今WEB2.0如火如荼的年代，我们当然要把内容和显示分离，在CSS中进行配置！当然实际问题要比这个文档说的略微复杂一点，有下面几个比较明显的问题：

1) 一般来说，大部分html标签(包括Input)都不要，但<Select> 要必须要在CSS中强制指定"font-family"为"SimSun-18030"。
2) 当要为一个元素指定多个字体的时候，要将"SimSun-18030"作为首选，即放在最前面。
3) 对于大部分标签,当font-family设为 SimSun-18030 时，而font-size 为：8pt,9pt,11px 时，有一部分字符比如 "㊣"和一些标点 会显示成其他的字符，对 "㊣" 这样的字符，IE 会出现乱码。原因可能是因为这些个font-size针对WEB做了优化。

小结：GB18030是个形式大于内容的东西，但是如果想要让你的产品理直气壮的再中国销售，略微花点时间设置一下还是有必要的。