http://feed.cnblogs.com/blog/u/12973/category/77507/rss2012-05-27T20:35:06Zfeed.cnblogs.comhttp://www.cnblogs.com/JeffreyZhao/archive/2011/05/16/jscex-write-sexy-javascript-slide.html

上周末，在风景秀丽的浙江大学校园内，举行了NodeParty杭州站的活动。我在活动上结合Node.js项目对Jscex进行了简单介绍，包括其设计目的，设计原则，使用方式，高级模式，组成部分等等。在场的许多朋友也提出了不少问题，我也一一作了解答或是演示。总体感觉还算不错，毕竟是亲手编写的项目，对其各方面还是了然于胸的。在此发布演讲用的幻灯片，希望能给不在现场的同学带来一些帮助。

2011-05-16T06:06:00Z2011-05-16T06:06:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2011/04/22/jscex-released-under-bsd-license.html

这次打算把Jscex好好搞一下了，其实很少会有技术方面的障碍能“轮到”我们去突破，但我觉得Jscex的确有机会，HTML 5、Node.js各个都是红火的玩意儿。前几天我花了两个晚上用半生不熟的中式英语写了一篇自认为比较完整的说明文字放到了Github上的项目首页上，没想到几个小时后便收到了StratifiedJS（一个与Jscex目标有些类似的项目）作者的邮件，提到了一些关于StratifiedJS的事情。我向他咨询了StratifiedJS的某些细节问题，也向他简单介绍了Jscex的实现原理。如今Jscex已经使用BSD授权协议正式发布（中文站也会在近期推出），再进行一些细节上的优化便要开始作推广了。

2011-04-21T16:18:00Z2011-04-21T16:18:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2011/04/15/jscex-status-uglifyjs-parser-and-aot-compiler.html

Jscex项目是我为了简化JavaScript异步的一个类库，支持任意JavaScript（ECMASCript 3）引擎。Jscex小巧而强大，可以极大地改善前端的AJAX及动画等场景的编程体验，同样也可以用在node.js进行服务器开发。从产生Jscex的想法到现在也有几个月的时间了，也一直想设法进行推广。在思考过程也发现了它在实际生产中可能会遇到的问题，于是前两个星期的主要工作，便是针对这些问题进行优化。首先我将Jscex的JavaScript分析器从Narcissus换成了UglifyJS，并基于node.js开发了一个简单的AOT编译器。接下来我也打算写个稍微详细一点的介绍，然后在国外社区看看反响如何。

2011-04-14T18:09:00Z2011-04-14T18:09:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/http://www.cnblogs.com/JeffreyZhao/archive/2009/09/22/how-to-use-fragment-cache-lazy-load-and-library-eazy.html

片段缓存已经实现完整了，但好像还没有提到如何在项目中进行实际应用，那么现在就来谈一谈这方面。之前也有朋友提出，这个片段缓存难道节省的只是拼接HTML字符串的时间吗？这其实就涉及到片段缓存在实际项目中该如何使用的问题了。我们通过延迟加载来省下数据加载的开支，而且有了Eazy类库之后，定义延迟加载是件非常容易的事情。

2009-09-22T06:54:00Z2009-09-22T06:54:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/片段缓存已经实现完整了，但好像还没有提到如何在项目中进行实际应用，那么现在就来谈一谈这方面。之前也有朋友提出，这个片段缓存难道节省的只是拼接HTML字符串的时间吗？这其实就涉及到片段缓存在实际项目中该如何使用的问题了。我们通过延迟加载来省下数据加载的开支，而且有了Eazy类库之后，定义延迟加载是件非常容易的事情。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/22/aspnet-mvc-fragment-cache-3-rendering-principle.html

上一篇文章里已经把Html.Cache打造成了非常具有可用性的API，需要缓存时我们只需在页面上做一个标记即可。标记内部的写法和普通视图的写法相同，RenderPartial等辅助方法输出内容也会被一并缓存下来。只可惜，上次文章末尾我提到有些效果是有前提的。这个前提就是必须修改RenderPartial的实现，让它遵守一个原则：如果您是在向页面输出内容，请务必将所有内容通过页面的Writer输出。

2009-09-22T03:05:00Z2009-09-22T03:05:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/上一篇文章里已经把Html.Cache打造成了非常具有可用性的API，需要缓存时我们只需在页面上做一个标记即可。标记内部的写法和普通视图的写法相同，RenderPartial等辅助方法输出内容也会被一并缓存下来。只可惜，上次文章末尾我提到有些效果是有前提的。这个前提就是必须修改RenderPartial的实现，让它遵守一个原则：如果您是在向页面输出内容，请务必将所有内容通过页面的Writer输出。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/21/aspnet-mvc-fragment-cache-2-more-friendly-api.html

上一篇文章中我们提出了了片断缓存的基本方式，也就是构建HtmlHelper的扩展方法Cache，接受一个用于生成字符串的委托对象。但是在实际开发过程中，我们最乐于看到的使用方法，应该只是使用某个标记来“围绕”一段现有的代码。不过这个方法并不实用，如果您要缓存大片的HTML，还需要准备一个Partial View，再用它来生成网页片段。这次我们会构建一个更为良好的API。

2009-09-21T07:49:00Z2009-09-21T07:49:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/上一篇文章中我们提出了了片断缓存的基本方式，也就是构建HtmlHelper的扩展方法Cache，接受一个用于生成字符串的委托对象。但是在实际开发过程中，我们最乐于看到的使用方法，应该只是使用某个标记来“围绕”一段现有的代码。不过这个方法并不实用，如果您要缓存大片的HTML，还需要准备一个Partial View，再用它来生成网页片段。这次我们会构建一个更为良好的API。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/17/aspnet-mvc-fragment-cache-1.html

说到网站性能优化，没有什么比“缓存”更重要了。即便是某些朋友口中念念不忘的“静态页”，说到底也只是缓存了整张页面内容而已。但是，显然这样大粒度的缓存策略，在如今“牵一发而动全身”的Web 2.0站点中几乎是无法使用的。视图片断缓存，缓存的也是页面内容，它比更低级别的缓存更有效率，也比静态页等整页内容缓存的适用面要大得多。在Rails或Django中都有类似的功能，但ASP.NET MVC甚至在2.0的Road Map中还没有包含这一功能，我们只能自己动手丰衣足食了。不过有了ASP.NET WebForm作为强大的视图引擎，加这样的功能简直是举手之劳。

2009-09-17T09:19:00Z2009-09-17T09:19:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/说到网站性能优化，没有什么比“缓存”更重要了。即便是某些朋友口中念念不忘的“静态页”，说到底也只是缓存了整张页面内容而已。但是，显然这样大粒度的缓存策略，在如今“牵一发而动全身”的Web 2.0站点中几乎是无法使用的。视图片断缓存，缓存的也是页面内容，它比更低级别的缓存更有效率，也比静态页等整页内容缓存的适用面要大得多。在Rails或Django中都有类似的功能，但ASP.NET MVC甚至在2.0的Road Map中还没有包含这一功能，我们只能自己动手丰衣足食了。不过有了ASP.NET WebForm作为强大的视图引擎，加这样的功能简直是举手之劳。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/15/standard-webformview-patch-and-MvcPatch-project.html

上一篇文章中我提到WebFormView的实现破坏了IView对象设计思路，它会把视图内容直接生成至HttpContext.Current而不是Render方法指定的TextWriter中。之前我提出了一种非常临时，非常山寨，非常简陋，绕弯，但是可行，或者说是可以“表现出解决问题的方法”的代码，而这次我们来做一次“标准”的修改。此外，我还创建了一个MvcPatch项目来保存这些内容。

2009-09-15T04:11:00Z2009-09-15T04:11:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/上一篇文章中我提到WebFormView的实现破坏了IView对象设计思路，它会把视图内容直接生成至HttpContext.Current而不是Render方法指定的TextWriter中。之前我提出了一种非常临时，非常山寨，非常简陋，绕弯，但是可行，或者说是可以“表现出解决问题的方法”的代码，而这次我们来做一次“标准”的修改。此外，我还创建了一个MvcPatch项目来保存这些内容。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/14/webviewengine-bug-always-render-to-current-context.html

最近需要搞一些重要的功能，结果又遇到了意料外的障碍。于是又仔细地看了看ASP.NET和ASP.NET MVC的源代码，又发现了以前不曾知道的一些细节。其实ASP.NET为我们留下了不少切入点，但几乎没什么书会提到这些切入点，我们只能从微软自己的框架中一探究竟。不过这次我想谈的是ASP.NET MVC框架中的一个Bug，这个Bug在一般情况下不会出现问题，但是这的确违反了ASP.NET MVC自身的设计。这个问题就出在WebFormView对象的实现上。

2009-09-14T07:33:00Z2009-09-14T07:33:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/最近需要搞一些重要的功能，结果又遇到了意料外的障碍。于是又仔细地看了看ASP.NET和ASP.NET MVC的源代码，又发现了以前不曾知道的一些细节。其实ASP.NET为我们留下了不少切入点，但几乎没什么书会提到这些切入点，我们只能从微软自己的框架中一探究竟。不过这次我想谈的是ASP.NET MVC框架中的一个Bug，这个Bug在一般情况下不会出现问题，但是这的确违反了ASP.NET MVC自身的设计。这个问题就出在WebFormView对象的实现上。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/03/ignore-some-arguments-when-constructing-url-via-expression-tree.html

您的使用ASP.NET MVC的时候，一定遇到过使用Post接受数据的Action方法。为了实现这个功能，我们必须在客户端准备一个form，并填写它的Action——也就是Post的目标URL。按照传统的做法，我们会使用表达式树来构造这个URL，但因为ASP.NET Routing在处理配置规则中没有标明的Route Values时，会将它们作为Query String拼接在URL后面。因此，我们需要得到一种“忽略”某个参数的方式。

2009-09-03T03:37:00Z2009-09-03T03:37:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/您的使用ASP.NET MVC的时候，一定遇到过使用Post接受数据的Action方法。为了实现这个功能，我们必须在客户端准备一个form，并填写它的Action——也就是Post的目标URL。按照传统的做法，我们会使用表达式树来构造这个URL，但因为ASP.NET Routing在处理配置规则中没有标明的Route Values时，会将它们作为Query String拼接在URL后面。因此，我们需要得到一种“忽略”某个参数的方式。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/01/make-expression-tree-based-url-construction-faster.html

我们继续改进通过表达式树构造URL的方式。在上一篇文章中，辅助方法可以正确地识别了ActionNameAttribute，而这次改进的则是性能方面的问题。原先的代码使用了传统计算一个表达式树的方式：“使用LambdaExpression对象封装，再编译，最后执行”来获得一个Expression对象的值。但是，Compile方法的性能是比较低下的，如果密集地执行会对性能产生一定影响。我们可以使用FastLambda中的组件来优化这部分操作的性能。

2009-09-01T11:29:00Z2009-09-01T11:29:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/我们继续改进通过表达式树构造URL的方式。在上一篇文章中，辅助方法可以正确地识别了ActionNameAttribute，而这次改进的则是性能方面的问题。原先的代码使用了传统计算一个表达式树的方式：“使用LambdaExpression对象封装，再编译，最后执行”来获得一个Expression对象的值。但是，Compile方法的性能是比较低下的，如果密集地执行会对性能产生一定影响。我们可以使用FastLambda中的组件来优化这部分操作的性能。http://www.cnblogs.com/JeffreyZhao/archive/2009/09/01/get-action-name-from-expression-tree-by-ActionNameAttribute.html

在MvcFutures项目中提供了一个辅助方法，可以将一个表达式树对象转化成一个RouteValueDictionary集合。只可惜，这个辅助方法的毛病比较多。例如，它直接把方法名作为action的值，而忽略了其上标记的ActionNameAttribute。这导致了某个被“改名”的Action方法一旦用在了表达式树中，最终得到的URL便是错误的。不过只需寥寥数行代码便可改变这个情况。

2009-09-01T06:25:00Z2009-09-01T06:25:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/在MvcFutures项目中提供了一个辅助方法，可以将一个表达式树对象转化成一个RouteValueDictionary集合。只可惜，这个辅助方法的毛病比较多。例如，它直接把方法名作为action的值，而忽略了其上标记的ActionNameAttribute。这导致了某个被“改名”的Action方法一旦用在了表达式树中，最终得到的URL便是错误的。不过只需寥寥数行代码便可改变这个情况。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/31/build-url-from-expression-tree-for-DomainRoute.html

由于DomainRoute支持针对URL域名的捕获和构造，这有些破坏了ASP.NET Routing所制定的“协议”（ASP.NET Routing只支持Path），因此在上一篇文章中，我们需要自己构造一个辅助方法来获得一个“包含域名”的URL。不过根据尽可能强类型的原则，我们应该使用的是类似于MvcFutures中定义的基于表达式树的辅助方法。由于MvcFutures已经提供了非常充足的辅助功能，因此这其实并不需要耗费我们多少代价。

2009-08-31T07:48:00Z2009-08-31T07:48:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/由于DomainRoute支持针对URL域名的捕获和构造，这有些破坏了ASP.NET Routing所制定的“协议”（ASP.NET Routing只支持Path），因此在上一篇文章中，我们需要自己构造一个辅助方法来获得一个“包含域名”的URL。不过根据尽可能强类型的原则，我们应该使用的是类似于MvcFutures中定义的基于表达式树的辅助方法。由于MvcFutures已经提供了非常充足的辅助功能，因此这其实并不需要耗费我们多少代价。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/26/url-building-method-for-DomainRoute.html

上一篇文章中我们构造了DomainRoute类，这是一个将URL Routing扩展至域名的Route组件，于是现在我们便可以轻易地从一个URL的Domain部分中捕获数据并在程序中使用。不过作为URL Routing的另一个重要部分，在URL构建方面，我们还需给DomainRoute补充额外的支持。

2009-08-26T04:18:00Z2009-08-26T04:18:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/上一篇文章中我们构造了DomainRoute类，这是一个将URL Routing扩展至域名的Route组件，于是现在我们便可以轻易地从一个URL的Domain部分中捕获数据并在程序中使用。不过作为URL Routing的另一个重要部分，在URL构建方面，我们还需给DomainRoute补充额外的支持。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/25/url-routing-with-domain.html

经常有朋友问我，如何对域名作URL Routing，他们可能希望根据域名（或自域名）来获得一些值，最终影响Controller，Action或某些参数的选择。之前我只是简单地说“扩展一下ASP.NET Routing吧”，而现在由于自己也正好需要使用这个功能，便实现了一个扩展。使用下来，效果不错。

2009-08-25T08:00:00Z2009-08-25T08:00:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/经常有朋友问我，如何对域名作URL Routing，他们可能希望根据域名（或自域名）来获得一些值，最终影响Controller，Action或某些参数的选择。之前我只是简单地说“扩展一下ASP.NET Routing吧”，而现在由于自己也正好需要使用这个功能，便实现了一个扩展。使用下来，效果不错。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/24/domain-parser-based-on-parsedroute.html

之前谈了不少关于ASP.NET Routing中ParsedRoute的内容，例如它的设计以及如何调用它的功能，其目的便是为了如今的使用作准备。现在我们就基于它构建一个Domain Parser，而这个Parser也是为今后的功能打基础的。

2009-08-24T10:27:00Z2009-08-24T10:27:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/之前谈了不少关于ASP.NET Routing中ParsedRoute的内容，例如它的设计以及如何调用它的功能，其目的便是为了如今的使用作准备。现在我们就基于它构建一个Domain Parser，而这个Parser也是为今后的功能打基础的。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/24/more-on-ParsedRoute.html

ParsedRoute是ASP.NET Routing中的内部类，作用是根据既定模式将一段URL解析为一个RouteValueDictionary。上次的文章中我主要谈了如何利用反射使用类库的内部成员，而这次则想分享一些使用ParsedRoute时产生的一些想法。

2009-08-24T06:10:00Z2009-08-24T06:10:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/ParsedRoute是ASP.NET Routing中的内部类，作用是根据既定模式将一段URL解析为一个RouteValueDictionary。上次的文章中我主要谈了如何利用反射使用类库的内部成员，而这次则想分享一些使用ParsedRoute时产生的一些想法。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/20/controller-factory-with-area-supporting.html

由于项目需要，把ASP.NET MVC 2中的Area功能搬到1.0上来吧……其实只是借用个Area名头而已，根本不是那么一回事。有时候，我们就为自己的项目做一点简单的扩展，不是很合适吗？

2009-08-20T03:33:00Z2009-08-20T03:33:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/由于项目需要，把ASP.NET MVC 2中的Area功能搬到1.0上来吧……其实只是借用个Area名头而已，根本不是那么一回事。有时候，我们就为自己的项目做一点简单的扩展，不是很合适吗？http://www.cnblogs.com/JeffreyZhao/archive/2009/08/19/use-the-internal-feature.html

经常看我博客的人可能会知道，我是一个喜欢搞点小技巧来实现某个功能的人。例如博客的皮肤，自己花了不少时间定义，也是为了效果丰富一些。当然，搞得最多的是从框架或类库内部取出一点小功能来用用，节省自己开发的时间。

2009-08-19T10:59:00Z2009-08-19T10:59:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/经常看我博客的人可能会知道，我是一个喜欢搞点小技巧来实现某个功能的人。例如博客的皮肤，自己花了不少时间定义，也是为了效果丰富一些。当然，搞得最多的是从框架或类库内部取出一点小功能来用用，节省自己开发的时间。http://www.cnblogs.com/JeffreyZhao/archive/2009/08/18/windows-live-writer-wysiwyg.html

Windows Live Writer的最大优势之一，便是可以自动获取目标博客的样式，然后让用户在特定的样式环境下编写文章。我们可以利用它在特定样式环境下编写HTML内容，这篇文章将会提供一个指南，希望可以帮助您打造一个合适的编辑环境。

2009-08-17T16:14:00Z2009-08-17T16:14:00ZJeffrey Zhaohttp://www.cnblogs.com/JeffreyZhao/Windows Live Writer的最大优势之一，便是可以自动获取目标博客的样式，然后让用户在特定的样式环境下编写文章。我们可以利用它在特定样式环境下编写HTML内容，这篇文章将会提供一个指南，希望可以帮助您打造一个合适的编辑环境。