Allen的自由天空

有财富未必有人生,有人生未必有财富

导航

从javascript语言本身谈项目实战(转载)

                                                   从javascript语言本身谈项目实战
随着ajax的升温,javascript越来越得到人们的重视。重要的是,ajax在一定程度上带来了web软件架构上的变化,人们把越来越多的功能分配到客户端实现,javascript子项目规模越来越大。如何更高效的使用javascript,如何更科学的组织javascript,如何更顺利的保证项目进展?我想就我的经验谈一点浅见。
一。 开发人员需要认真学习javascript语言本身
       由于javascript是“[url =http://www2.uuzone.com/blog/555080192/18957.htm]世界上最被误解的语言[/url]”, 大部分人对javascript语法并没有全面了解过,只是凭借看起来很像c或者java的关键字按照自己的理解写javascript代码。其实 javascript是一种很独特的语言,和c++/java有非常大的区别,要想用javascript做大一些的项目,开发人员必须老老实实的学习 javascript的语法。真正掌握了语法后,我们才不会把delete看成释放内存对象,才不会为到底参数传递是值传递还是引用传递而烦恼。真正理解了javascript的基于原型的OO方式,才可能写出具有良好架构的javascript程序。
       《javascript权威指南》是一本最合适的书,郑重推荐。另外ECMA262 文档可以作为参考。网上流行的jscript手册chm版本使用起来比较方便,不过这是微软的jscript实现,和标准的javascript略有区别,使用时应该注意上面的注脚信息。关于javascript的原型和OO,网上已经有很多文章介绍了,在此不再多说。
二。 良好的代码来源于良好的设计
       只有设计优良,代码才会写的漂亮。现在的javascript子项目已经不是以前web项目中的“边角料”和散兵游勇了,在较大的ajax项目内, javascript将非常复杂,ajax的异步模型也和以前顺序执行的程序设计有所区别。所以建议做javascript前首先做好设计。推荐使用用例驱动的方式,把用例分析清楚,以便全局考虑所有可能的页面交互过程,绘出页面内一些对象之间的交互图,分析一些数据对象的状态,作出精细的 javascript设计。
三。 使用设计模式,复用其他领域的设计经验
        如果javascript非常复杂,可以考虑使用一些模式。我想大部分做javascript的开发者都不是“javascript科班”出身吧 掌握了javascript的语言本质,就可以复用我们在其他领域的经验了。使用javascript框架或者ajax框架,使用单例模式做一个全局的数据缓冲池,或者使用观察者模式把界面对象和数据对象分离,使用命令模式实现用户的操作队列等等。
四。 调试代码的技巧
        javascript的代码不太好调试,这是由于:
    * 一般的开发人员对javascript语言本身不太精通。也就是上面提到的。
    * web项目包含较多的因素,复杂性加剧。服务端脚本、模板、html、js等很多环节都可能增加调试难度。
    * 浏览器存在兼容性问题。有可能在一个细节问题上IE、Mozilla、opera等浏览器都有差异。
    * 工具的缺乏。虽然mozilla的jsdebugger非常好用(还有bug,比如eval时调试器有些问题),但是其他浏览器环境下调试工具就不怎么样了。ms系统自带的script debug工具调试本地代码还可以,直接调试网站js代码表现欠佳。opera除了javascript控制台外我没有找到其他调试工具。
       在此我推荐几个调试技巧:
   1. 使用Mozilla firefox的jsdebugger插件。这个我不再多说了,最经典的js调试工具。在线调试远程站点的javascript效果非常棒。
   2. 把问题隔离,建立本地的html文件和js文件,使用ms script debug调试工具来调试。如果js模块比较独立,可以使用这个工具的。如果写hta的项目,这个工具当然是首选了。
   3. httpWatch 这是一个ie下的插件,非常好用,能够监视ie中的任何http会话,并能够看到http会话的原文。可以通过这个工具了解你的程序有没有和服务器产生会话,参数&返回的数据到底是什么。
   4. 在网页内建立用于调试的textarea
      可以在网页内建立一个textarea来接受你想运行的js语句,然后加一个按钮使用js的eval函数执行你输入的代码。
      这种方式非常适合在线调试,网页出错后写代码输出页面内的对象值。建议写一些dump工具函数配合使用,效果更佳。
      我非常喜欢这种方式,可以随时使用开关打开页面内隐藏的textarea进行调试,感觉很像给一台服务器接上了终端,然后使用shell可以做任何事情 函数可以在这里重新定义,可以任意操作界面中的任何元素,调用任何对象的任何函数,输出任何你需要的运行时刻值。
   5. 使用异常(exception)和断言(assert)
      使用try{}catch(e){}结构不光可以屏蔽出错信息,让界面更友好。我们的程序可以使用异常、抛出异常来构建一种更好的出错处理机制。
      有这样一个故事,我在使用string.localeCompare函数时随手写了这样的代码:
      var iRe = str1.localeCompare(str2);
      switch(iRe){
      0: return ....
      1: return ....
      -1:return ....
      defalut:throw "error:localeCompare return other value"
      }
      写完就忘了,没想到我的同事在linux下使用firefox时,异常被抛出了,然后我们得知:linux firefox下localeCompare返回的不只是0/1/-1,而是返回一个具体值.
      这个异常抛出有效的检测出了代码的不完美。
      firefox下的异常dump后能得到较为详细的调用栈信息,这一点非常好。IE的异常信息没有这么详细。
      异常和断言也可以结合成为一个非常有效的调试工具。
      断言(assert)是在其他语言中的一种很有效的调试工具,常常以这种形式出现:
      assert( <条件> ) ;
      在程序处于debug状态,当条件为假时,系统中止运行并报告这个断言。由于断言是我们自己定义的,所以我们可以很容易的判断出出错的地方,进而找到bug所在。
      javascript语言没有提供宏,也没有提供assert,我们可以这样模拟
      if(_is_debug) assert = function(expression , strLable){
          if( !expression ) throw Error(strLable);
      }
      else assert = function(){};//_is_debug是一个全局变量
      这样可以实现在发生"不可能的事情"的时候,让程序在调试模式下抛出异常,在发布版本中不作理会。
      可以这样输出当前栈的调用信息,弥补刚才提到的IE中异常对象没有栈信息的缺陷:
      function callStackInfo(){
      var s="",line="";
      var cer=arguments.callee.caller;
      while(cer){
      var sf=cer.toString();
      s+=line+sf.substring(sf.indexOf('function'),sf.indexOf('{'))+"\n";
      line=".."+line;
      cer=cer.caller;
      }
      return s;
      }
       本文只就javascript在web开发,特别是在ajax方面的开发做了一些讨论,主要在于管窥如何更好的使用“纯javascript”。web开发还有很多其他方面,比如xml和Dom等实际上和javascript息息相关,但是本文没有涉及,还请见谅。欢迎各位朋友就我的讨论多提意见。
 
 
 
 
 
转一篇好文,助大家更好的理解javascript

JavaScript的目的
写于 2006年11月19日,在ppk on JavaScript 学习笔记分类下
从今天起,我将陆续将 ppk on JavaScript 的读书心得发布到这个blog上。ppk是我所景仰的一位web开发者,原因无它,只是因为作为一个JavaScript的开发者来说,他涉及的领域包括web标准,可用性,无障碍等,正是其他开发者所不关注或者故意忽略的。并且,他写了很多案例测试不同的浏览器,总结出JavaScript的接口(API)兼容性,成为JavaScript开发者重要参考资料,几年如一日,这种钻研精神是很多人所缺乏的。
ppk在今年9月出版了他的书,我从去年起就在等的书。今天拿到手,迫不及待地把第一章阅读完毕。果然让人充满惊喜,他的功力非同一般。虽然只是一个初学者,但我认为我已经走在正确的学习道路上。我想,我若能将学习心得分享,能让正在学习的人看到,可以一起交流一起进步,尽管我不敢确保你能从我这里得到什么启发,但我可以确信,我这些笔记会比你拷贝粘贴代码的学习方式更正确。
这本书有十章,章名都简洁明了,分别是:目的,背景,浏览器,准备,核心,BOM, 事件,DOM, CSS更改和数据获取。从来没有一本书能如此简洁地明确JavaScript的方方面面,因此学习不会有太大负担。前言不宜过多,下面就开始我的第一章学习笔记。
开篇宗义:JavaScript的目的是,为网页增加特别的一层可用性。听起来很简单,但这条黄金定律经常被人误解。就算编写有用的JavaScript, 开发者可能还是没能结合适当的情景:Web标准运动发展下,与当代无障碍的HTML页面的配合。更为不妙的是,有些开发者不是为网页增加一层可用性,而是用整层取代之,后果是,如果浏览器不支持JavaScript, 网站就完了。
概念概述
JavaScript是一门由浏览器解释的脚本语言。它通过在客户端而不是服务器端处理某些交互,比如表单验证,创建新菜单来给网站增添可用性。传统的网页交互是,客户端的一举一动都必须经过服务器端的出来才能反馈回来,漫长的等待会让用户崩溃。而JavaScript可以在客户端代替服务器端做某些事情(最明显的,表单验证),从而提高用户体验。
随着时代的发展,JavaScript能够处理越来越多的交互。问题出现了,JavaScript能做这么多事情,到底要多用还是少用?这就有了富与瘦的对决。是整个页面都用JavaScript来控制交互还是只增加些许的JavaScript来增强可用性?就是说,尽可能地使用JavaScript还是有所节制,甚至不用?
瘦客户端很大程度上依赖于客户端-服务器的通讯,而富客户端尽可能限制额外的数据通讯。
哪种方式更好?尽管富客户端带来一些可用性益处,但瘦客户端可能是更“标准”的JavaScript用法。Web被认为是文档集合,而不是界面集合。最明显的证据是,浏览器有后退前进的功能让你在文档中跳转而界面会有么?浏览器可以收藏(书签)文档而界面可以么?从无障碍来说,瘦客户端也更少出错。
这种非平衡性是很难解决的。富客户端当然也可以在更高级的界面做到前进后退,或者收藏,也可以做到完美的无障碍。这必须需要大量的额外工作,但不是每个项目都有超出预算的时间或金钱。此外,太过专注于可用性而忽略无障碍也是一个问题。
那么JavaScript的目的是为富客户端还是瘦客户端服务?答案是:看情况。得看你的网站,你的受众,你的JavaScript水平。
技术概述
JavaScript分为六个方面,分别是核心(Core),浏览器对象模型(BOM),事件(Events),文档对象模型(DOM),CSS变更和数据获取(XMLHttpRequest)。
上古时代,NetScape领头之时,NetScape3是事实标准。
当代却没有这么简单。ECMA标准化JavaScript Core, W3C标准化DOM,而BOM尚在WHAT-WG的标准化中,W3C也刚有了XMLHttpRequest的第一份草稿。今天,BOM依然遵循NetScape3的事实标准,而XMLHttpRequest还是遵照Microsoft的原始规范。
JavaScript的目的在于为网站增加可用性,而不是破坏用户的隐私和安全。因此JavaScript不允许读写用户的文件(cookies除外),采取同源策略,只允许来自相同域的交互。不允许读取历史记录,不能为上传文件的表单设置值,由JavaScript控制的窗口关闭需经用户确认,由JavaScript打开的窗口不能小于100×100的窗口,不能移出屏幕之外。
JavaScript的历史
探寻历史才能让我们知道JavaScript为什么会被误解得如此深。JavaScript的创造者是Brendan Eich,首次在NetScape 2中实现。它的目的是创建一门足够简单的语言让开发者能容易地为网页增加交互,只要把代码拷贝过来调整一下就可以。这确实令人赞叹,很多JavaScript开发者是从拷贝粘贴开始的。
不幸的是JavaScript生错了名字,也生错了语法。最初它叫LiveScript,但1996年的时候Java炙手可热,NetScape想搭顺风车,于是某产品经理(我想知道她/他是谁,呵呵),命令更名,命令Brendan Eich让“Javascript像Java”。这让很多人误认为JavaScript是Java的低级版,不能引起严肃程序员的关注。
1996年之时,NetScape 3是王,Microsoft只能照抄。这是一个难得的和谐期,当然,那时候浏览器比起现在来“瘦”了,仅限于表单验证,鼠标轮换的一些小花招而已。
接下来就是影响深远的浏览器大战了。为了争夺市场,两家浏览器纷纷实现不同的东西,谁都想成为事实标准。最有名的就是NetScape 4的document.layer和IE 4的document.all(忘记它们吧!)。它们让DHTML流行起来。
1999年Microsoft以推出良好支持CSS和DOM的IE5胜出,NetScape的让位终于有足够的时间让一场革命发生,那就是CSS。WaSP首先从CSS入手,而很多专家也发现/发明了许多浏览器的补救办法,让这场革命成为可能。
2003年,一些先锋们在CSS革命的影响下开始探索新的JavaScript风格,更多地关注无障碍,改观人们对它的坏名声,那就是unobstrusive——把JavaScript从HTML结构层分离出来,遗憾的是,那些在浏览器大战存活下来的程序员可能还没有发现这条新道路。
2005年,Ajax热潮为JavaScript社区注入新的血液。但某些方面,Ajax太像DHTML了,无障碍,是很多Ajax应用的难言之隐。这个热潮趋向于关注技术(如何Ajax),而可用性和交互(为何Ajax)却被低估。最后,各种肿胀的库(现在称为框架)迅速发展起来。
Ajax依然全速前进,但这会像DHTML一样结果,人们渐渐失去兴趣,它们会土崩瓦解。
JavaScript兴衰史好像有一定的“定律”支配,我们能打破这个怪圈吗?不管如何,JavaScript开发者在寻找各种酷代码和华而不实的框架之外,更应该调整自己的行动,让JavaScript运行在:标准兼容的,无障碍的网页中。

posted on 2007-09-30 15:24  AllenFeng  阅读(241)  评论(0编辑  收藏  举报