??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
<!--
var WshShell=new ActiveXObject("WScript.Shell");
WshShell.RegWrite("HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\Domains\\YouTest.com","");
WshShell.RegWrite("HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\Domains\\YouTest.com\\www","");
WshShell.RegWrite("HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings\\ZoneMap\\Domains\\YouTest.com\\www\\http","2","REG_DWORD");
alert("写入成功");
//-->
</SCRIPT>
Jpxx.forceLogout()Ҏ(gu)通过AJAX技术来强制注销用户Q即调用session.invalidate()Ҏ(gu)?
转蝲:http://www.jpxx.org/?tid=54
var strTest="试Test";
alert(strTest.length);
//昄?Q他把一个汉字当作一自字W,而我需要得到的l果?Q也是把汉字当成两个字W?/p>
以上Ҏ(gu)只能求汉字加子母的情情况Qؓ(f)求gؓ(f)1的情况就?x)生异怺(jin)
以上Ҏ(gu)能解x(chng)字,字母Q数据合的情况
Let’s consider this issue using a simple example. Suppose that you want to build a tree-structured bulletin board system which loads the data for each article by communicating with the server according to user requests rather than loading all articles at one time from the server. Each article has 4 pieces of information associated with it: a unique ID within the bulletin board system, the name of the person who posted the article, the content of the article, and an array of the IDs of its child articles. To begin with, let’s assume that there is a JavaScript function named getArticle()
which is responsible for loading a single article. This function receives the integer ID of the article to be loaded as an argument, and it retrieves the data of the article with that ID from the server. It then returns an object which has the 4 pieces of information contained in that article: id, name, content
, and children
. An example of this function in use can be written like this:
function ( id ) {
var a = getArticle(id);
document.writeln(a.name + "<br>" + a.content);
}
As you may notice, calling this function many times with the same article ID, however, requires communications with the server again and again for no good reason. To counter this problem, consider the function getArticleWithCache()
, which is a getArticle()
with a cache capability. In this example, the data loaded by getArticle()
will be simply retained as a global variable:
var cache = {};
function getArticleWithCache ( id ) {
if ( !cache[id] ) {
cache[id] = getArticle(id);
}
return cache[id];
}
Now the articles that have been read are cached. Now, let’s consider the function backgroundLoad()
, which loads the data of all articles based on this mechanism. This function aims to preload all of the child articles in the background while the user is reading a given article. Because the article data is tree structured, a recursive algorithm can easily be written which traverses the tree and allows all articles to be loaded:
function backgroundLoad ( ids ) {
for ( var i=0; i < ids.length; i++ ) {
var a = getArticleWithCache(ids[i]);
backgroundLoad(a.children);
}
}
The backgroundLoad()
function receives an array of IDs as an argument and applies our previously-defined getArticleWithCache()
to each ID. This allows the data of the article corresponding to each ID to be cached. Then, by recursively calling backgroundLoad()
on the IDs of the child articles of the loaded article, the entire article tree is cached.
So far, everything looks good. If you have worked on AJAX application development, however, you should know that this naïve implementation won’t work successfully. The example has been based on the tacit understanding that getArticle()
uses synchronous communication. As a general rule, however, JavaScript requires the use of asynchronous communication in communicating with the server because it has only a single thread. In terms of simplicity, processing everything (including GUI events and rendering), on one thread is a good programming model, because it eliminates the need to think about the complicated problems associated with thread synchronization. On the other hand, it presents a significant problem in developing applications –which appear responsive to the user because the single-thread environment cannot respond to users’ mouse clicking and/or key operation when the thread is working on something else (such as the getArticle()
call).
What happens if synchronous communication is carried out within this single-threaded environment? Synchronous communication stops the browser’s execution until the communication result is obtained. The thread cannot respond to users while waiting for the communication result because the call from the server has not been completed, and the thread will remain blocked until the call returns. For this reason, it can not respond to users while it is waiting for the server’s response and the browser therefore looks frozen. This also holds true for the execution of getArticleWithCache()
and backgroundLoad()
, which are based on getArticle()
. Because may take a considerable amount of time to download all of the articles, the browser freezing during that time is a serious problem for backgroundLoad()
- since the browser is frozen, it is not possible in the first place to achieve the goal of preloading the data in the background while users are reading articles, since the article will be unreadable.
Since the use of synchronous communication creates a significant problem in usability as described above, JavaScript uses asynchronous communication as a general rule. Therefore, let’s rewrite the program above based on asynchronous communication. JavaScript requires asynchronous communications to be written in an event-driven programming style. In most instances, you specify a callback function which is called once the communication response has been received. For example, getArticleWithCache()
defined above can be rewritten as:
var cache = {};
function getArticleWithCache ( id, callback ) {
if ( !cache[id] ) {
callback(cache[id]);
} else {
getArticle(id, function( a ){
cache[id] = a;
callback(a);
});
}
}
This program also internally calls the getArticle()
function. It should be noted, however, that the version of getArticle()
which is designed for asynchronous communication expects to receive a function as the second argument. When this version of getArticle()
is called, it sends a request to the server, as before, however the function returns immediately without waiting for a response from the server. This means that when the execution is returned to the caller, the server response has not yet been retrieved. This allows the thread to work on other tasks until the server response is obtained and the callback function is called. As soon as this response is received from the server, the callback function specified as the second argument of getArticle()
is invoked with the server’s response as an argument. Likewise, getArticleWithCache()
has been changed so that it will expect a callback function as the second argument. This callback function will then be called within the callback function that is passed to getArticle()
so that it will be executed after the server-communication is finished.
You may think that the above rewriting alone is rather complicated, but the backgroundLoad()
function involves even more complicated rewriting. It can be also rewritten to handle a callback function:
function backgroundLoad ( ids, callback ) {
var i = 0;
function l ( ) {
if ( i < ids.length ) {
getArticleWithCache(ids[i++], function( a ){
backgroundLoad(a.children, l);
});
} else {
callback();
}
}
l();
}
This rewritten backgroundLoad()
function does not look much like our original function, however there is no difference in what they do. This means that both functions receive an array of IDs, call getArticleWithCache()
on each element of the array, and recursively apply backgroundLoad()
to the resultant child articles. However, it is not easy to recognize even the loop structure for the array, which was represented by a for-statement in the original program. Why are these two sets of functions that do the same thing so totally different from each other?
The difference results from the fact that any function must return immediately after any function that requires server-communication, such as getArticleWithCache()
. The callback function that should receive the server response cannot be called unless the original function is no longer executing. For JavaScript, it is not possible to suspend the program in the middle of loops, such as for-statements, and resume it later at the point where execution was suspended; the loop is therefore represented by recursively passing the callback function instead of using a loop syntax. For those who are familiar with Continuation-Passing Style (CPS), this is a manual implementation of CPS. Because no loop syntax can be used, even the simple program described earlier that traverses a tree requires complicated statements. The problem associated with event-driven programs is known as the control flow problem: loop and other control flow statements are likely to be difficult to understand.
There is another problem: if you convert a function which does not use asynchronous communication into a function that uses asynchronous communication, the rewritten function will need to have a new parameter which is a callback functions. This poses a significant problem to existing APIs since our internal changes will not remain internal, but will result in broken APIs and changes by others using our API.
What is the root cause of all of these problems? That’s right. The fact that JavaScript has only one thread causes the problems. Carrying out asynchronous communication on only one thread requires an event-driven program and complicated statements. If another thread could respond to users while the program is waiting for the server response, acrobatics like this would not be required.
Let me talk about Concurrent.Thread, a library that allows JavaScript to use multiple threads, since this greatly eases the difficulty associated with asynchronous communication in the AJAX development mentioned above. This is a free-software library implemented in JavaScript, available under the Mozilla Public License / GNU General Public License. You can download the source code from the website.
Let’s download and use the source code right away. Suppose that you have saved the downloaded source code as a file named Concurrent.Thread.js. Before doing anything else, let’s run the program below, which has a very naïve implementation:
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/javascript">
Concurrent.Thread.create(function(){
var i = 0;
while ( 1 ) {
document.body.innerHTML += i++ + "<br>";
}
});
</script>
Executing this program should display numbers starting with 0 in order. Numbers appear one after another, which you can view by scrolling the page. Now, let’s look at the source code in more detail. It uses a simple infinite loop as indicated by while ( 1 )
. In ordinary cases, a JavaScript program like this continues to use the one and only thread, causing the browser to look frozen. Naturally, it does not allow you to scroll the screen. Then, why does the above program allow you to scroll? The key is Concurrent.Thread.create()
located above while ( 1 )
. This is a method provided by the library; it is for creating a new thread. On a new thread, the function passed as the argument is executed. Let me slightly rewrite the program as follows:
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/javascript">
function f ( i ){
while ( 1 ) {
document.body.innerHTML += i++ + "<br>";
}
}
Concurrent.Thread.create(f, 0);
Concurrent.Thread.create(f, 100000);
</script>
In this program we have a new function f()
, which shows numbers repeatedly. This is defined at the top, and the create()
method is called twice with f()
as arguments. The second argument passed to the create()
method is passed to f()
without modification. Executing this program shows some small numbers starting with 0, which are followed by some large numbers starting with 100,000 and small numbers again that follow up the first series of small numbers. Like this, you can observe that the program shows alternating lines of small numbers and large numbers. This indicates that two threads are running concurrently.
Let me show you another use of Concurrent.Thread. In the above example, the create()
method was called to create a thread. It is also possible to create a thread without calling any library APIs at all. For example, the former example can be expressed as:
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
var i = 1;
while ( 1 ) {
document.body.innerHTML += i++ + "<br>";
}
</script>
Inside the script tag, an infinite loop is written simply in JavaScript. You should take note of the type attribute of the tag: an unfamiliar value (text/x-script.multithreaded-js
) is assigned to it. If this attribute is assigned to the script tag, then Concurrent.Thread executes the content of the tag on a new thread. You should remember that, in this case as well, the library body of Concurrent.Thread must be included.
With Concurrent.Thread, it is possible to switch execution context from one thread to another as needed even if you write a long and continuous program. Let me briefly talk about how this behavior is achieved. In short, code conversion is used. Very roughly speaking, the function passed to the create()
method is first converted to a character string, which is then rewritten so that it can be executed on a piecemeal basis. Then, the rewritten function is executed little by little on the scheduler. The scheduler is responsible for coordinating multiple threads. In other words, it makes adjustments so that each of the rewritten functions will be evenly executed. Concurrent.Thread actually does not create new threads but simply simulates a multi-threaded environment on the original single thread.
Although the converted functions appear to be running on different threads, there is actually only one thread running everything. Carrying out synchronous communication within the converted functions will still cause the browser to freeze. You may think that our original problem has not been solved at all, however you don’t have to worry. Concurrent.Thread provides a purpose-built communications library which is implemented using the asynchronous JavaScript communication style and which is designed to allow the other threads to work even when a thread is waiting for a response from the server. This communications library is found under the Concurrent.Thread.Http
namespace. For example, it is used as follows:
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
var req = Concurrent.Thread.Http.get(url, ["Accept", "*"]);
if (req.status == 200) {
alert(req.responseText);
} else {
alert(req.statusText);
}
</script>
The get()
method retrieves the content of the specified URL using HTTP GET
, as its name suggests. It takes a target URL as the first argument and an array representing HTTP header fields as the optional second argument. The get()
method communicates with the server and returns an XMLHttpRequest object as the return value when it has received the server response. When the get()
method returns, the response had been received. It is not necessary to use a callback function to receive the result. Naturally, there is no worry that the browser freezes while the program is waiting a response from the server. In addition, the post()
method can be used to send data to the server:
<script type="text/javascript" src="Concurrent.Thread.js"></script>
<script type="text/x-script.multithreaded-js">
var req = Concurrent.Thread.Http.post(url, "key1=val1&key2=val2");
alert(req.statusText);
</script>
The post() method takes a destination URL as the first argument and content body to be sent as the second argument. As with the
get()
method, you can also assign header fields by the optional third argument.
If you implement getArticle()
in the first example using this communications library, then you can quickly write getArticleWithCache()
, backgroundLoad()
, and other functions that use getArticle()
using the naïve method shown at the beginning of this article. Even when that version of backgroundLoad()
is reading article data, another thread can respond to users as a matter of course, and the browser therefore does not freeze. Now, do you understand how useful it is to use multiple threads in JavaScript?
转蝲:http://www.infoq.com/articles/js_multithread
ie7昄出来的checkbox居然是未选中的但是alert出来的却是trueQ而FF一切正?br />
后来查了(jin)半天资料说是ie昄的时候只对状态改变比较敏?br />
Ҏ(gu)
var echkbox=document.createElement("input");
echkbox.setAttribute("type","checkbox");
echkbox.setAttribute("id","inputid");
echkbox.setAttribute("name","inputname");
echkbox.setAttribute("value","inputvalue");
var addhere=document.getElementById("someElementId");
addhere.appendChild(echkbox);
echkbox.setAttribute("checked","checked");
alert(document.getElementById("inputid").checked);
一切ok
radio同样是这U情c(din)?/font>
firefox下代?/p>
IE代码
我们有一这L(fng)?/span>
我们现在要把q棵?wi){化成如下的表格样?/span>
通过表格我们可以看出Q他有三部䆾Q主栏,宾栏Q主体,而主栏,是一颗向叛_开的树(wi)Q宾栏是一颗向下展开的树(wi)Q而主体部份则是一个表?/span>
表格的整体布局
L
HTMLl构
<DIV>
<DIV>
<DIV>李宁DIV>
<DIV></DIV>
</DIV>
<DIV></DIV>
<DIV>
<DIV>?/span>/DIV>
<DIV></DIV>
<DIV>上衣DIV>
<DIV></DIV>
</DIV>
<DIV></DIV>
</DIV>
宾栏
HTMLl构
<DIV>
<DIV>
<DIV>大区</DIV>
<DIV></DIV>
</DIV>
<DIV></DIV>
<DIV>
<DIV>华北</DIV>
<DIV></DIV>
<DIV>华中</DIV>
<DIV></DIV>
</DIV>
<DIV></DIV>
</DIV>
M
HTMLl构
<DIV>
<DIV>
<DIV>l</DIV>
<DIV></DIV>
</DIV>
<DIV>
</DIV>
</DIV>
其中在HTML中边框全部采用宽度或高度?PX的DIV构成
在div布局中,横向展开采用的属性是float="left"
我设计的Jscȝ构图如下
一个由?wi){化ؓ(f)表格的程序就完成Q但是在开发过E中Q有时候也到一些问题,如效率等Q如有哪位对q控件或报表开发方面有兴趣的,大家一起交?span lang="EN-US">
从事?jin)数q的Web开发工作,来觉得现在对WEB开发有?jin)更高的要求。要写出漂亮的HTML代码Q要~写_致的CSS样式表展C每个页面模块;要调?a >javascriptl页面增加一些更zL的要素;要用Ajaxl用户带来更好的体验。一个优U的WEB开发h员需要顾?qing)更多层面,才能交出一份同样优U的作业。ؓ(f)帮助q大正处于Web2.0z流中的开发h员,在这里ؓ(f)大家介绍一ƾ轻巧灵zȝ辅助开发工兗?/p>
Firebug是Firefox下的一Ƒּ发类插gQ现属于Firefox的五星强力推荐插g之一。它集HTML查看和编辑、Javascript控制台、网l状늛视器于一体,是开发JavaScript、CSS、HTML和Ajax的得力助手。Firebug如同一把精巧的瑞士军刀Q从各个不同的角度剖析Web面内部的细节层面,lWeb开发者带来很大的便利。这是一ƾ让人爱不释手的插gQ如果你以前没有接触q它Q也许在阅读本文之后Q会(x)有一试的Ʋ望。笔者在撰写此文的时候,正逢Firebug发布1.0正式版,q不能不说是Uy合?br />
Firebug插g虽然功能强大Q但是它已经和Firefox览器无~地l合在一P使用单直观。如果你担心(j)它会(x)占用太多的系l资源,也可以方便地启用/关闭q个插gQ甚至针对特定的站点开启这个插件?/p>
在安装好插g之后Q先用Firefox览器打开需要测试的面Q然后点d下方的绿色按钮或使用快捷键F12唤出Firebug插gQ它?x)将当前面分成上下两个框架Q如?所C?/p>
?QFirebug插g展开囄
从图1中看刎ͼFirebug?个主要的Tab按钮Q下文将主要介绍介绍q几斚w的功能?/p>
Console | HTML | CSS | Script | Dom | Net |
控制?/td> | Html查看?/td> | Css查看?/td> | 脚本条时? | Dom查看?/td> | |络状况监视 |
控制台能够显C当前页面中的javascript错误以及(qing)警告Qƈ提示出错的文件和行号Q方便调试,q些错误提示比v览器本w提供的错误提示更加详细且具有参考h(hun)倹{而且在调试Ajax应用的时候也是特别有用,你能够在控制台里看到每一个XMLHttpRequestshpost出去的参数、URLQhttp头以?qing)回馈的内容Q原本似乎在q后黑匣子里q作的程序被清清楚楚地展C在你面前?/p>
象C shell或Python shell一P你还能在控制C查看变量内容Q直接运行javascript语句Q就是大段的javascriptE序也能够正运行ƈ拿到q行期的信息?/p>
控制台还有个重要的作用就是查看脚本的log, 从前你也怹(fn)惯了(jin)使用alert来打印变量,但是Firebugl我们带来了(jin)一个新朋友 —?console.log, 最单的打印日志的语法是q样的:(x)
如果你有一堆参数需要组合在一赯出,可以写成q样Q?/p>
Firebug的日志输出有多种可选的格式以及(qing)语法Q甚臛_以定制彩色输出,比v单调的alertQ显然更加方便,限于幅Q这里不做详l说明,但是有志于提高debug效率的读者,可以到Firebug的官方站点(见附录)(j)查看更详l的教程?/p>
?Q?在控制台里调试javascript
W一ơ看到Firebug强大的HTML代码查看器,p得它与众不同Q相比于Firefox自带的HTML查看器,它的功能强大?jin)许多?HTML
首先你看到的是已l经q格式化的HTML代码Q它有清晰的层次Q你能够方便地分辨出每一个标{之间的从属q行关系Q标{折叠功能能够帮助你集中精力分析代码。源代码上方q标记出?jin)DOM的层ơ,如图3所C,它清楚地列出?jin)一个hml元素的parent、child以及(qing)root元素Q配合F(tun)irebug自带的CSS查看器用,?x)给div+css面分析~写带来很大的好处。你q可以在HTML查看器中直接修改HTML源代码,q在览器中W一旉看到修改后的效果Q光凭这一点就?x)让许多面设计师死心(j)塌地地成?f)Firebug的粉丝了(jin)?/p>
有时候页面中的javascript?x)根据用L(fng)动作如鼠标的onmouseover来动态改变(sh)些HTML元素的样式表或背景色QHTML查看器会(x)页面上改变的内容也抓下来,q以黄色高(sh)标记Q让|页的暗操作彻底成为历双Ӏ?/p>
利用Inspect(g)查功能,我们q可以用鼠标在页面中直接选择一些区块,查看相应的HTML源代码和CSS样式表,真正的做到所见即所得,如果你用了(jin)外部~辑器修改了(jin)当前|页Q可以点击Firebug的reload囄重新载入|页Q它?x)l跟t你之前用Inspect选中的区块,方便调试?/p>
?:QHTML查看?br />
Firebug的CSS调试器是专ؓ(f)|页设计师们量n定做的?/p>
如今的网设计言必称div+cssQ如果你是用table套出来的HTML面Q就得按q规矩重构一遍,否则昑־你不够时髦!用div做出来的面的确能精HTML代码QHTML标签减肥的结果就是CSS样式表的~写成了(jin)面制作的重头戏。Firebug的CSS查看器不仅自下向上列出每一个CSS样式表的从属l承关系Q还列出?jin)每一个样式在哪个样式文g中定义。你可以在这个查看器中直接添加、修攏V删除一些CSS样式表属性,q在当前面中直接看C改后的结果?/p>
一个典型的应用是面中的一个区块位|显得有些不太恰当,它需要挪动几个象素。这时候用CSS调试工具可以L~辑它的位置——你可以Ҏ(gu)需要随意挪动象素?br /> 如图4中正在修改一个区块的背景艌Ӏ?/p>
提示Q如果你正在学习(fn)CSS样式表的应用Q但是总记不住常用的样式表有哪些|可以试在CSS调试器中选中一个样式表属性,然后用上下方向键来改变它的|它会(x)把可能的g个个遍历l你看?/p>
?: CSS查看器,能够直接修改样式?br />
我们可以利用Firebug来查看页面中某一区块的CSS样式表,如果q一步展开右侧Layout tab的话Q它?x)以标尺的Ş式将当前区块占用的面U清楚地标识出来Q精到象素Q更让h惊讶的是Q你能够在这个可视化的界面中直接修改各象素的|面上区块的位置׃(x)随改动而变化。在面中某些元素出现错位或者面U超出预料值时Q该功能能够提供有效的帮助,你可以籍此分析offset、margin、padding、size之间的关p,从而找?gu)决问题的办法?/p>
?QFirebug中的CSS标尺
也许有一天,你的老板或者客hCQ抱怨你制作的网速度奇慢Q你该如何应对?你或怼(x)说这可能是网l问题,或者是?sh)脑配置问题Q或者是E序太慢Q或者直说是他们的h品问题?不管怎么_(d)最后你可能被要求去解决q个有多U可能的问题?/p>
|络状况监视器能帮你解决q个手问题。Firebug的网l监视器同样是功能强大的Q它能将面中的CSS、javascript以及(qing)|页中引用的囄载入所消耗的旉以矩状图呈现出来Q也许在q里你能一把揪出拖慢了(jin)你的|页的元Ӟq而对|页q行调优Q最后老板满意客户Ƣ喜Q你的饭也因此而牢固?/p>
|络监视器还有一些其它细节功能,比如预览囄Q查看每一个外部文件甚x(chng)xmlHttpRequestsh的http头等{?/p>
?Q网l状늛视器
q是一个很不错的javascript脚本调试器,占用I间不大Q但是单步调试、设|断炏V变量查看窗口一个不。正所谓麻雀虽小Q五脏俱全?/p>
如果你有一个网站已l徏成,然而它的javascript有性能上的问题或者不是太完美Q可以通过面板上的Profile来统计每D脚本运行的旉Q查看到底是哪些语句执行旉q长Q一步步排除问题?/p>
?Qjavascript调试?br />
DOM(Document Object Model)里头包含?jin)大量的Object以及(qing)函数、事Ӟ在从前,你要想从中查到需要的内容Q绝非易事,q好比你M(jin)一个巨大的图书馆,惌扑ֈ几本名字不太切的小书,众多的选择?x)让你无所适从。而用Firebug的DOM查看器却能方便地览DOM的内部结构,帮助你快速定位DOM对象。双M个DOM对象Q就能够~辑它的变量或|~辑的同Ӟ你可能会(x)发现它还有自动完成功能,当你输入document.get之后Q按下tab键就能补齐ؓ(f)document.getElementByIdQ非常方ѝ如果你认ؓ(f)补齐得不够理惻I按下shift+tab又会(x)恢复原状。用?jin)Firebug的DOM查看器,你的javascript从此扑ֈ?jin)驱使的对象QW(xu)eb开发也许就成了(jin)一件乐事?/p>
?: Dom查看?br />
Firebug插g提供?jin)一整套web开发所必需的工兗从HTML的编写,到CSS样式表的化调优Q以?qing)用javascript脚本开发,亦或是Ajax应用QFirebug插g都会(x)成ؓ(f)你的得力助手。所谓工Ʋ善其事Q必先利其器。在Web2.0的时代,a必称AjaxQ动辄就是用户体验提升,如果把Firebug工具用好Q必能让你如虎添|HTML、CSS、javascript整理得服服帖帖,从此成ؓ(f)web开发中的专家人物?/p>
Firebug的中文含义是萤火虫,作者是Joe HewittQ官方网?http://www.getfirebug.com
Firefox亦即火狐览器,是近q来撼动IE览器市(jng)场占有率的一支强大力量,要不是它的出玎ͼ我想有生之年说不定也看不到IE 7的发布了(jin)Q官方网?http://www.firefox.com
但是他对(g)错方面没有myesclipse的好Q对于有一些警告和错误它不能提C出?/p>
对于javasctipt调试工具Q也有好几种可选择的方?׃机器比较慢,我采用的是firefox+firebug来调试,在网上找?jin)一介l的文gQ等下把它帖出来Q开?Net的h都知道,vs是一个很不错的调试javasctipt工具Q我以前也一直用q个来调试javasctipt,不过专门用来调试javasctiptQ可以说是大材小用了(jin)
引用:http://book.csdn.net/bookfiles/11/100117056.shtml
对于JavaScriptQ同h可能创徏外部客户不能讉K的私有属性,而只能通过对象的(公用Q方法来讉KQ但q一点很有人知道。Douglas Crockford[3]提出?jin)一U在JavaScript中创建私有属性的Ҏ(gu)。这U方法非常简单,ȝ如下Q?/font>
l U有属性可以在构造函C使用var关键字定义?/font>
l U有属性只能由Ҏ(gu)函数Qprivileged functionQ公用访问。特权函数就是在构造函C使用this关键字定义的函数。外部客户可以访问特权函敎ͼ而且Ҏ(gu)函数可以讉K对象的私有属性?/font>
下面来考虑前一个示例中的VehiclecR假设你惌wheelCount和curbWeightIn- Pounds属性是U有的,q只能通过公用Ҏ(gu)讉K。新的Vehicle对象如代码清?-4所C?/font>
代码清单5-4 重写后的Vehicle对象
注意QwheelCount和curbWeightInPounds属性都在构造函C使用var关键字定义,q就使得q两个属性是U有属性。属性不再是公用的,如果想通过点记法访问wheelCount属性的|如下Q?/font>
var numberOfWheels = vehicle.wheelCount;
׃(x)q回undefinedQ而不是wheelCount实际的倹{?/font>
׃属性现在是U有的,因此需要提供能讉Kq些属性的公用函数。getWheelCount、setWheelCount、getCurbWeightInPounds和setCurbWeightInPounds函数是作此使用的。现在Vehicle对象可以保证只能通过公用函数讉KU有属性,因此满?jin)信息隐藏?/font>
引用:http://book.csdn.net/bookfiles/11/100117056.shtml