posts - 114,  comments - 17,  trackbacks - 1
  2008年9月30日

 

 

.aspx设置AutoEventWireup=false情况下,Page_Load方法没有办法成为Load事件的订阅者,

我们必须手工进行相应的subscribe,不然我们就看不到输出的hello.

 

<%@ Page Language="C#" AutoEventWireup="false" CodeFile="Default.aspx.cs" Inherits="_Default" %>

 

public partial class _Default : System.Web.UI.Page

{

    protected override void OnInit(EventArgs e)

    {

        base.OnInit(e);

        this.Load += this.Page_Load;

    }

 

    protected void Page_Load(object sender, EventArgs e)

    {

        Response.Write("hello");

    }

}

 

 

从这个简单例子,可以看出AutoEventWireup=true时候像Page_xx都成为了保留方法了。

posted @ 2008-09-30 22:35 shawnliu 阅读(19) | 评论 (0)编辑

 

51aspx推荐使用WebApplication

本文将向大家简单介绍一下VS2005中WebSite和WebApplicationd的区别,希望能够对大家有所帮助。
  WebApplication编程模型的优点:
  ●网站编译速度快,使用了增量编译模式,仅仅只有文件被修改后,这部分才会被增量编译进去。
  ●生成的程序集
  WebSite:生成随机的程序集名,需要通过插件WebDeployment才可以生成单一程序集WebApplication:可以指定网站项目生成单一程序集,因为是独立的程序集,所以和其他项目一样可以指定应用程序集的名字、版本、输出位置等信息
  ●可以将网站拆分成多个项目以方便管理
  ●可以从项目中和源代码管理中排除一个文件
  ●支持VSTS的Team Build方便每日构建
  ●更强大的代码检查功能,并且检查策略受源代码控制
  ●可以对编译前后进行自己规定的处理
  ●对App_GlobalResources 的Resource强类支持
  ●直接升级使用VS2003构建的大型系统
  WebSite编程模型的优点:
  ●动态编译该页面,马上可以看到效果,不用编译整个站点(主要优势)
  ●同上,可以使错误的部分和使用的部分不相干扰
  ●可以每个页面生成一个程序集
  ●可以把一个目录当做一个Web应用来处理,直接复制文件就可以发布,不需要项目文件
  ●可以把页面也编译到程序集中
  两种编程模型的互相转换:
  VS2005 SP1内置了转换程序,可以非常方便的从WebSite转换到WebApplication
  只需要复制文件,右键执行“转换为Web应用程序”即可。
  未查到有专门的反向转换工具,但比较后发现如果转换也非常简单。
  *.designer.cs
  *.aspx
  *.ascx
  *.master
  删除所有*.designer.cs
  将*.aspx、*.ascx、*.master页面文件中的 Codebehind="FileList.aspx.cs" 批量替换成 CodeFile="FileList.aspx.cs"
  总之,大网站比较适合用WebApplication项目,小网站比较适合用WebSite项目。

 

 

     以下是网友对WebApplication和WebSite的讨论

问者:zhuangjunx(星晨)
大家在用vs.net2005开发网站的时候,是用WebApplication方式还是WebSite方式呀???
--------------------------------------------------------------------------------
答者:nowitzki41(德克,MVP)
WebSite
--------------------------------------------------------------------------------
答者:zhuangjunx(星晨)
WebSite方式在发布网站时,整个网站怎么生成一个dll文件?
--------------------------------------------------------------------------------
答者:xrascal(横刀夺爱)
Web Application
--------------------------------------------------------------------------------
答者:xiaoyue34561()
VS2005里 哪来的Web Application??
--------------------------------------------------------------------------------
答者:xiaoyue34561()
反正我用的 WebSite
--------------------------------------------------------------------------------
答者:gnhao(何飞)
WebSite方式在发布网站时,整个网站怎么生成一个dll文件?
源码没什么好保留的。。。。。。
你可能新建一个WEB控件库。让每个类继承至Page然后在改一下ASPX页面里的继承相关设置就行了
--------------------------------------------------------------------------------
答者:gnhao(何飞)
Page也是一个控件
--------------------------------------------------------------------------------
答者:flyin2006(败家子_看技术帖,回水贴)
WebSite方式在发布网站时,整个网站怎么生成一个dll文件?
-------------
生成解决方案->生成网站
--------------------------------------------------------------------------------
答者:chy710(懂你)
WebSite方式在发布网站时,整个网站可以生成一个dll文件,请参考:chy710.cnblogs.com里的文章
只有vs2005 sp1才有Web Application
--------------------------------------------------------------------------------
答者:xrascal(横刀夺爱)
打了补丁就有 web application 了

--------------------------------------------------------------------------------
答者:zhuangjunx(星晨)
WebSite方式在发布网站时,整个网站生成一个dll文件,是不是要用WebDeployment补丁?
--------------------------------------------------------------------------------
答者:webdiyer
WebSite方式在发布网站时,整个网站生成一个dll文件,是不是要用WebDeployment补丁?

是的,或者你装sp1
51aspx.com
--------------------------------------------------------------------------------
答者:vengair(韦恩)
VS 2005 做网站开发时 网站项目已经没有工程文件了
VS 2003 是有工程文件的 也就是 WebApplication
--------------------------------------------------------------------------------
答者:livant(水横枝)
顺便问一句,这两个哪一个好点?
有什么区别吗?
--------------------------------------------------------------------------------
答者:sp1234(51aspx.com)
我曾经试验了一两天项目方式,还是觉得目录方式干净简单,不容易出管理问题。
如果你有什么不想编译的文档,放在app_code目录下就可以。然后我发布的时候都是“不允许修改预编译内容”、“不选择固定命名”。我的一个项目,本工程的代码编译出来有40多个共4M多dll,编译进一个文件,那么上传得时候就太容易出问题了。
另外,推荐一个我用的比较舒服的网站上传软件:NetLoad。不要用普通的 FTP 客户端软件上传,那个太笨了。
--------------------------------------------------------------------------------
答者:sp1234(遭遇 Adware.CPush 流氓)
如果你有什么不想编译的文档  -->  如果你有什么不想发布的文档
我当初曾经想用项目方式管理,就是因为当时不知道目录方式下如何保存不想发布的文档。
编译为一个大dll,是网站很忌讳的,从上传、装载、更新都很麻烦和危险。
从管理上说,我过去经常遇到需要手工(盲目地)修改工程文件的情况,例如项目的Web位置的有冲突了。去掉工程文件,反而从来没有出现过那类问题,真的很放心。
--------------------------------------------------------------------------------
答者:zhuangjunx(星晨)
那就是用WebSite方式比较好了???
--------------------------------------------------------------------------------
答者:wzhh598(Watchouwa)
vs2005下只有“项目”"网站",只有当生成网站的时候才会有WebSite
--------------------------------------------------------------------------------
答者:zhuangjunx(星晨)
WebApplication 方式在发布时,能替换修改的文件,而不是全部替换,这样在上传修改的文件时,就不需要全部上传了。这样不是更方便,WebSite只能全部替换吧?
--------------------------------------------------------------------------------
答者:zhuangjunx(星晨)
WebApplication 方式在发布时,能替换修改的文件,而不是全部替换,这样在上传修改的文件时,就不需要全部上传了。这样不是更方便,WebSite只能全部替换吧?
--------------------------------------------------------------------------------
答者:adow(adow)
我一直用website,更新时方便吧,只要替换修改文件就可以了。
--------------------------------------------------------------------------------
答者:chjlcn
WebSite,感觉WEbSite速度快点。仅仅是直觉。没有测试过。
--------------------------------------------------------------------------------
答者:SEYON(小白)
生成解决方案->发布网站

--------------------------------------------------------------------------------
答者:luckbird(luckbird)
Web Application
--------------------------------------------------------------------------------
答者:oberserver()
大站点还是用Web Application 好

 

zz from:http://bbs.51aspx.com/showtopic-744.html

posted @ 2008-09-30 18:37 shawnliu 阅读(16) | 评论 (0)编辑

ps:偶主要用的是web site,因为deploy时候可以每个文件对应一个dll,替换很方便

 

ASP.NET 2.0 - Web Site vs Web Application project

Ref: http://maordavid.blogspot.com/2007/06/aspnet-20-web-site-vs-web-application.html

A common question by asp.net developers is what project model should I use for asp.net application? Web Site project (which introduced with VS 2005) or Web Application project (which delivered as add-in for VS 2005 and built-in within VS 2005 SP1)?

There is no thumb rule. Every project model has it's own advantages (and diss-advantages off course...). I hope this post will help you to understand better the differences between 2 of them.

Web Application project model

  • Provides the same Web project semantics as Visual Studio .NET 2003 Web projects.
  • Has a project file (structure based on project files).
  • Build model - all code in the project is compiled into a single assembly.
  • Supports both IIS and the built-in ASP.NET Development Server.
  • Supports all the features of Visual Studio 2005 (refactoring, generics, etc.) and of ASP.NET 2.0 (master pages, membership and login, site navigation, themes, etc).
  • Using FrontPage Server Extensions (FPSE) are no longer a requirement.

Web Site project model

  • No project file (Based on file system).
  • New compilation model.  (Read here or here for more details) and ...
  • Dynamic compilation and working on pages without building entire site on each page view.
  • Supports both IIS and the built-in ASP.NET Development Server.
  • Each page has it's own assembly.
  • Defferent code model.  (Read here for more details)

Ok, all is great, but you want to create your web site now. Which model should you use?

  • You need to migrate large Visual Studio .NET 2003 applications to VS 2005? use the Web Application project.
  • You want to open and edit any directory as a Web project without creating a project file? use Web Site project.
  • You need to add pre-build and post-build steps during compilation? use Web Application project.
  • You need to build a Web application using multiple Web projects? use Web Application project.
  • You want to generate one assembly for each page? use Web Site project
  • You prefer dynamic compilation and working on pages without building entire site on each page view? use Web Site project
  • You prefer single-page code model to code-behind model? use Web Site project.
posted @ 2008-09-30 18:31 shawnliu 阅读(23) | 评论 (0)编辑
  2008年9月18日


 Alma Whitten: 负责综合计算机安全及可用性工作,及计算机安全用户中心
  Ben Goodger: Firefox首席工程师
  Biz Stone: Blogger 资深专家(Blogger)
  Bo Cowgill
  Bret Taylor 
  Chris DiBona: 开放源码程序经理 
  Colin Smith 
  Darin Fisher: Firefox首席工程师
  Dave Barr 
  Devinoch: Adwords 代表
  Doe Mountain 
  Douwe Osinga: 搜索工程师(Google驻欧洲工程办事处) 
  Eric Case (Blogger) 
  Graham Waldon (Blogger) 
  Greg Rae: 网络日志分析师
  Greg Stein: 工程经理(Blogger) 
  Jason Shellen: 程序经理 (Blogger) 
  Jeremy Lilley: 软件工程师
  John Hawkins 
  Joseph 
  Josh MacDonald 
  Kenny Smith 

 


  Kevin Fox: 用户接口设计师
  Kimbalina: 招聘负责人(Blogger) 
  Mark Ayzenshtat 
  Natala Menezes: 帐户经理 
  Nelson Minar: 网络API工程师
  Oliver Deighton 
  Ovidiu Predescu 
  Paul Haahr: 软件工程师 
  Sanjay G. Mavinkurve 
  Tan Chade-Meng: 软件工程师 
  Wesley Chan: 产品经理/员工摄影师
  Will McNair

  另外,我们还收集了雅虎公司某些员工的博客地址,它们是:

  Bill Turner 
  Eric Burke 
  Ernie: 网络开发师 
  Jeremy Zawodny: 工程师( Yahoo搜索) 
  JR Conlin 
  Michael J. Radwin: 软件工程师
  Naveen Jamal 
  Ravi Dronamraju
posted @ 2008-09-18 17:17 shawnliu 阅读(19) | 评论 (0)编辑
  2008年9月16日

 

     大家都用过哪些啊?都是用在哪些场合?

     mq的应用主要是input和output的速度没办法很好的匹配,需要一个queue来缓冲这种速度差别。

     同时我们可以降低两边的耦合程度,使用队列也有某些persistent的优点。

 

posted @ 2008-09-16 18:03 shawnliu 阅读(26) | 评论 (0)编辑
  2008年9月7日
先看这张图
反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。 

通常的代理服务器,只用于代理内部网络对Internet的连接请求,客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器,普通代理服务器也被设计为在Internet上搜寻多个不确定的服务器,而不是针对Internet上多个客户机的请求访问某一个固定的服务器,因此普通的Web代理服务器不支持外部对内部网络的访问请求。当一个代理服务器能够代理外部网络上的主机,访问内部网络时,这种代理服务的方式称为反向代理服务。此时代理服务器对外就表现为一个Web服务器,外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于,这个服务器没有保存任何网页的真实数据,所有的静态网页或者CGI程序,都保存在内部的Web服务器上。因此对反向代理服务器的攻击并不会使得网页信息遭到破坏,这样就增强了Web服务器的安全性。 
反向代理方式和包过滤方式或普通代理方式并无冲突,因此可以在防火墙设备中同时使用这两种方式,其中反向代理用于外部网络访问内部网络时使用,正向代理或包过滤方式用于拒绝其他外部访问方式并提供内部网络对外部网络的访问能力。因此可以结合这些方式提供最佳的安全访问方式。
   
posted @ 2008-09-07 17:03 shawnliu 阅读(65) | 评论 (0)编辑
  2008年9月4日

想了解一下rails,刚好搜到这篇文章,感觉不错,就zz一下。

Ruby和Rails入门书籍的阅读指南

Programming Ruby(2nd Edition) 

这似乎已经不是怪事:关于一种编程语言的经典教材,作者不是这门语言的创造者。就像Stan Lippman之于C++、Joshua Bloch之于Java、Martin Fowler之于UML一样,Dave Thomas也许是这个世界上最善于向别人讲解Ruby语言的人——至少超过Matsumoto是毫无问题的。也许正是因为自己也经历了“不懂到懂”的学习过程,有时候“旁观者”反倒比“创造者”更清楚学习者们需要什么。 

   所以这本书就是Ruby的经典教材。关于Ruby的基本语法和常用工具,书中第一部分和第二部分做了详细的介绍。第三部分“Ruby Crystallized”更加阐述了Ruby语言的一些细节和设计理念,其中第23章“Duck Typing”是刚从Java或者.NET平台走出来的读者不可错过的,因为对于类型与契约的理解、对于类与类型的理解,正是Ruby这种动态语言与Java/C#等静态语言最大的区别之一。随后的第四部分提供了Ruby基础类库的速查手册。 

   Dave Thomas和Andy Hunt这两个“Pragmatic Programmer”并非浪得虚名:这本Programming Ruby虽然不是一本称职的参考手册,却足够帮助一个初学者步入Ruby世界而不致误入歧途,并且能够在很少见的一些情况下——譬如说忘了yield的用法——给有经验的Ruby程序员提供帮助。在我看来,这也就足够奠定它作为经典教材的地位了。由于封面上有一柄丁字镐,这本书也被昵称为“镐头书”——它正是你发掘“红宝石”(Ruby)宝藏的必备工具。 

Agile Web Development with Rails
  


Rails的作者David Heinemeier Hansson说过一句大实话:“我从来不会为了学语言而学语言。”大多数人在大多数时候学习一种新的语言不是为了比较语言的优劣,而是因为这个语言底下的某个工具能给他的工作带来帮助。Ruby世界里的这个“杀手应用”,让Ruby在短短一年时间里成为焦点的这个工具,就是Rails。 

   这是第一本介绍Rails的图书,又是由Rails的作者DHH和前面提到的Dave Thomas共同撰写,其价值可谓不言而喻了。许是两位作者有太多的“乾货”想要交给读者,这本书的第一版被他们——不幸地——写到了558页之厚。书中首先展示了一个规模不大的在线购物网站,让读者亲身体验用Rails进行敏捷开发的感受;然后针对Rails框架的各个组件和安全、部署等延伸话题展开了深入的讨论。其内容之全面、探讨之深入,令人叹为观止。看起来,和Matsumoto不同,DHH很清楚应该怎么介绍自己的作品——不管是“浅出”还是“深入”。 

   值得中国读者高兴的是,这本书的第一版已经由林芷薰翻译,电子工业出版社付梓。Rails仍然处在高速发展的阶段,从本书第一版截稿至今,Rails已经发生了相当大的变化,因此这本中译本甫一面世便已经有很多过时之处。但这本书毕竟不是参考手册,作者更多地是在其中阐述Rails的设计理念和最佳实践。对于英文阅读无法达到最快速度的读者来说,这个译本未尝不可以是一个称职的向导。 

Rails开发者助手两种 Ruby for Rails, Rails Recipes

   不难想象,有很多性急的程序员会——就像我一样——草草了解Ruby语法之后就一头扎进Rails的绚丽宫殿,体验快速开发web应用的成就感,却不得不时时因为缺乏对Ruby语言的深入了解而感到迷惑:这个类里什么都没有,它为什么会工作?那个地方写的代码是什么意思?可是,要全面系统地学习Ruby,又实在令人望而生畏。还好,我们有这本Ruby for Rails。书中介绍了一些Ruby语言特性——既有普通的也有高级的,都是Rails中使用到的。简而言之,这就是一本专门为Rails应用开发者提供的Ruby指南。更有趣的是,书中还用了一章(第17章)篇幅专门介绍“如何探索Rails源代码”,真可谓是“授人以渔”的典范了。 

   另一个“助手”则是Chad Fowler——他也是Programming Ruby的合着者——的Rails Recipes。和任何一本“菜谱”(recipe)一样,这本书不会教你如何使用菜刀与炒勺、如何把蔬菜切片——你可以从别的很多地方学到这些技巧。这本RailsRecipes教给读者的,是如何在 Rails环境下急就章地完成一个你需要的功能。譬如说“用户登录与身份验证”这件事,每个网站、每个开发者都曾经做过不止一次,这本书中就给了读者一个简单而可靠的解决方案,读者只要抄抄改改,几分钟就可以完成这个功能。对于初接触Rails(以及Web 2.0)、面对很多问题尚且无从下手的新兵来说,这本书确实可以帮助他们解决一些实际问题。 

   不过这本书的局限也同样明显:如果你需要的菜色超出了这份菜谱的范围,它就只好爱莫能助了;而且,仅仅给出解决问题的代码,却没有对应的单元测试,也让习惯了TDD的读者多少有些忐忑。在我看来,这本书对“授人以鱼”的专注恰好和前一本Ruby for Rails构成了一对“可怕的对称”,也让这两本书有理由共存于Rails开发者的案头。 

Ruby In A Nutshell

   作为Ruby语言的缔造者,Yukihiro Matsumoto只能写一本“果壳书”,这本身就是一件耐人寻味的事情。O’Reilly的“果壳书”系列历来褒贬不一:有人认为它们缺乏深度,也有人认为它们是快速入门的好帮手。但Matsumoto最大的问题在于:他创造了Ruby,却没有真正意识到这种语言到底有多大的威力——后来他经常在Ruby on Rails讨论组活动,从中了解一些精妙的Ruby用法。其结果也很自然:这本Ruby In A Nutshell作为语言参考中规中矩,但对于实际应用中的妙处——例如在DSL方面的应用——却语焉不详。再加上它所针对的Ruby版本是略显过时的1.6版,也让这本书的地位略显尴尬。 

Ruby 奇书两种  Enterprise Intergration with Ruby, Best of Ruby Quiz

   称它们为“奇书”,因为它们的主题实在偏颇。先看这本Enterprise Integration with Ruby:虽说脚本语言常常被称为“胶水”,有多少人会当真想到用Ruby去做企业应用集成?不过细看之下,这本书多少有些名不副实之嫌,因为它真正介绍的无非只是如何访问数据库、如何操作XML、如何通过SOCKET通信之类比较底层的技术而已。在一个生僻的题目之下写着另一些生僻的内容,尽管这些内容算得上有趣,但我还是要对那些没有读过这本书的Ruby程序员说:你没有错过太多——尽管这本书与你想象的并不一样。 

   最后要介绍的这本书更是备受争议:有人盛赞它是“精通Ruby的必经之路”,也有人批评它沉溺于奇技淫巧缺乏实用价值。但无论褒贬,更多的读者正在逐一挑战其中的谜题——这本书就是James Edward Gray所着的Best of Ruby Quiz。这本书(目前出版的是第一卷)列举了25道题目,读者大多可以想出一种办法来解决这些问题,往往还能 通过思考和重构找到第二种优雅的设计,但这本书却给你列出了第三种、第四种真正精巧的解决方案——充分利用Ruby技巧才能得出的解决方案。这些题目的最终解法之巧妙,常常令人拍案叫绝(或是破口大骂)。不过这些“奇技淫巧”也并非全无用处,例如书中很多题目在解答时都用到了正则表达式,理解这些解答对于深入学习正则表达式的用法是很有帮助的。

posted @ 2008-09-04 15:34 shawnliu 阅读(42) | 评论 (0)编辑


伯克利的教授Eric Brewer曾经做出过一个定理:所有的web服务都没有办法同时达到下面三个特性。

l  Consistency:这个容易理解

l  Availability:可用性,每次操作都能得到预想的返回结果。

l  Partition tolerance:当个别组成部分不work时候,操作本身也应该能够完成。

对于web应用程序,最多只能支持两种特性,而Partition tolerancescale out的根本之一,所以我们只能从一致性和可用性之间做一下tradeoff.有的业务需要我们放弃可用性来保持一致性,而很多业务又需要我们放弃一致性而更多的考虑可用性。Web应用应该更多的考虑可用性。所以我们的架构应该更多的思考BASE而不是ACID.简单来讲就是为了满足高负载的用户访问,我们可以容忍短暂的数据不一致。我们平常经常能够碰到这种情形。例如很多后台cache机制导致我们的更新过一段时间才能够有效。这显然不是ACID模式的特性。但是有的时候我们必须使用ACID的模式,例如我从卡里支付了5000块钱,如果你等半个小时才扣掉,这显然有问题啊。

posted @ 2008-09-04 01:15 shawnliu 阅读(29) | 评论 (0)编辑
  2008年8月24日

使用StreamReader等读取图片,结果破坏了格式。我知道应该使用binaryreader来读取,那为什么呢?

是不是和Encoding有什么关系,结果丢弃了图片内部某些二进制还是什么其它解释?一直都没有搞明白这些东西,

望大家指点一二。

posted @ 2008-08-24 17:04 shawnliu 阅读(189) | 评论 (2)编辑
  2008年8月4日

track from:http://royal.pingdom.com/?p=305

June 11, 2008

Which Javascript frameworks are the most common?

To answer that question, we here at Pingdom have examined a set of almost 200 popular websites to see if they use a Javascript framework, and in that case which framework they have chosen. The websites were collected from the Alexa US Top 100 and the Webware Top 100 Web Apps. The frameworks we looked for were Prototype, JQuery, MooTools, Yahoo! UI Library, Dojo, ExtJS and MochiKit.

We quickly saw that Dojo, ExtJS and MochiKit were not used at all by these sites, which lead us to focus on the other four in this article.

Logos for JS frameworks

Prototype

Prototype is one of the earlier Javascript frameworks and is also included in the Ruby on Rails framework. Of the websites in this test, a total of 13 used the Prototype framework.

JQuery

JQuery is a framework that has received a lot of attention due to its speed, size and smart modular approach which has led to a big library of plugins. Of the websites in this test, 11 used the JQuery framework.

MooTools

Just like other Javascript frameworks, MooTools contains several functions to help development. One of the more known ones is its advanced effects component. Of the websites in this test, four used the MooTools frameworks.

Yahoo! UI Library (YUI)

Yahoo has developed its own Javascript framework. They use it for their own websites, but have also made it freely available to others. Of the websites in this test, seven used the Yahoo! UI Library.

Websites that couldn’t decide

Some of the websites didn’t just use one framework, but several. This will force all visitors to download more than needed and should be avoided.

The reason for using more than one framework could either be that they want to use the best parts of several frameworks or that they simply started developing using one framework and then later decided to use another one and haven’t been able to migrate all of their code yet.

The ones using more than one framework were Digg (Prototype and JQuery), Bebo (MooTools and YUI) and YouSendIt (Prototype and YUI).

Conclusion

Prototype turned out to be the most-used framework in this survey, with JQuery not far behind. It was also interesting to see that several sites are using the Yahoo! UI Library. We had imagined that this number would be lower and that far more websites would be using Prototype and JQuery.

It should be noted that this survey doesn’t necessarily give a 100% complete picture since we only looked at the homepage of the websites. We also didn’t log in to any websites. And of course, we didn’t look for every single Javascript framework out there.


How the test was performed

We made a list of websites consisting of the Alexa US Top 100 and also Webware’s Top 100 Web Apps (minus actual applications such as Firefox and Skype). Using a special tool we then looked at all the websites after specific keywords to identify the frameworks.

For example, for Prototype we looked for the strings “prototype.js” and “/prototype” which should cover most variations of including the framework, unless the word “prototype” has been completely removed.

We also manually checked all sites that were found to contain references to the frameworks we tested for. In the case of the Yahoo! UI we excluded sites that only used its CSS framework and not any Javascript.

posted @ 2008-08-04 00:43 shawnliu 阅读(77) | 评论 (0)编辑