聽聽聽
Dojo鏄竴涓嬌鐢↗avascript緙栧啓鐨勫紑婧怐HTML宸ュ叿銆傚畠寤虹珛浜庡緢澶氬凡鎹愮尞鐨勪唬鐮佸熀紜錛坣Widgets銆丅urstlib銆乫(m)錛?榪?
鏄負(fù)浠涔堟垜浠皥鍒板畠鏈夋椂鏄竴涓?緇熶竴"鐨勫伐鍏楓侱ojo鑷村姏浜庤В鍐充竴浜涢暱鏈熷瓨鍦ㄧ殑浼撮殢DHTML鐨勫巻鍙查棶棰橈紝瓚熼樆姝㈠ぇ澶氭暟閲囩敤鍔ㄦ亀eb搴旂敤紼嬪簭寮鍙戙?br />
Dojo allows you to easily build dynamic capabilities into web pages and any other environment that supports JavaScript
sanely. You can use the components that Dojo provides to make your web
sites more useable, responsive, and functional聽 With Dojo you can build
degradeable user interfaces more easily, prototype interactive widgets
quickly, and animate transitions.聽 You can use the lower-level APIs and
compatibility layers from Dojo to write portable JavaScript
and simplify complex scripts. Dojo's event system, I/O APIs, and
generic language enhancement form the basis of a powerful programming
environment. You can use the Dojo build tools to write command-line
unit-tests for your JavaScript
code.聽 You can use the Dojo package system to make your code easier to
maintain and less platform dependent.聽 The Dojo build process helps you
optimize your JavaScript for deployment by grouping sets of files together and reuse those groups through "profiles".
Dojo鍏佽浣犲鏄撳湴寤虹珛鍔ㄦ佹ц兘鍒皐eb欏甸潰鍜屽叾浠栫ǔ鍋ユ敮鎸乯avascript鍦扮幆澧冧腑銆?浣犲彲浠ヤ嬌鐢―ojo鏀寔緇勪歡錛屽畠浣夸綘鐨剋eb绔欑偣鏇存湁鍙敤琛岀殑銆備即闅廳ojo,浣犲彲浠ユ洿瀹規(guī)槗鍦板緩绔媎egradeable鐢ㄦ埛鐣岄潰錛岃繀閫熷湴鍘熷瀷浜や簰楗頒歡鍜屽姩鐢昏漿鍙樸備綘鍙互浣跨敤搴曞眰鍦癮pi鍜屽吋瀹瑰眰錛屼粠Dojo鍒板啓杞諱究鐨凧avascript鍜岀畝鍗曞鏉傛暀鏈侱ojo鐨勪簨浠剁郴緇燂紝I/O api,鍜屾硾鍨嬭璦澧炲己緇勬垚寮哄ぇ鐨勭▼搴忕幆澧冪殑鍩虹銆?浣犲彲浠ヤ嬌鐢╠ojo寤洪犲伐鍏鋒潵涓轟綘鐨凧avascript浠ｇ爜鍐欏懡浠よ鍗曞厓嫻嬭瘯銆備綘鍙互浣跨敤Dojo 鍖呯郴緇熸潵浣垮緱浣犵殑浠ｇ爜鏇村鏄撳幓緇存姢鍜屾洿灝戝鉤鍙頒緷璧栥?Dojo寤洪犺繃紼嬪府鍔╀綘浼樺寲浣犵殑Javascript涓轟綘鐨勯儴緗詫紝瀹冮氳繃涓璧峰垎緇勬枃浠墮泦鍚堝拰閫氳繃"profile"閲嶇敤榪欎簺緇勩?
Dojo
does all of these things by layering capabilities onto a very small
core which provides the package system and little else. When you write
scripts with Dojo, you can include as little or as much of the
available APIs as you need to suit your needs. Dojo provides MultiplePointsOfEntry, InterpreterIndependence, ForwardLookingAPIs, and focuses on ReducingBarriersToAdoption.
Dojo澶勭悊鎵鏈夎繖浜涗簨鎯咃紝閫氳繃鍒嗗眰鑳藉姏鍒嗚В鎴愪竴浜涢潪甯稿皬鐨勫拰鏍稿績錛屽畠鏀寔鍖呯郴緇熷拰鍏朵粬鏇村皯鐨勩傚崟浣犲啓鏄嬌鐢―ojo鍐欒剼鏈紝浣犲彲浠ュ寘鍚綔涓哄緢灝戞垨
鑰呭悓鏍峰鍙敤鐨刟pi浣滀負(fù)浣犻渶瑕佹弧瓚充綘鐨勯渶瑕佺殑銆侱ojo鏀寔MutiplePointsOfEntry,
InterprerterIndependence, ForwardLookingAPIs,
鍜岄泦涓璕educingBarriersToAdoption.
Dojo
is being built around a single markup language that will provide
application authors with a (more) simple way of declaring and using
responsive DHTML interface components. Renderings may be made available
in several rendering contexts (such as SVG, or perhaps even the desktop
or Flash), but the markup language (DojoML) and scripting language (JavaScript) will not change. Better yet, the DojoML parser accepts extended HTML and SVG as valid input, and can be used to easily create DegradeableResponsiveApplications.
Dojo鏄竴涓寤洪犲湪涓涓崟涓鐨勬爣璁拌璦錛屽畠?yōu)畣鏀寔搴旂敤绋嬪簭浣滆呴噰鐢ㄤ竴涓紙澶氫釜錛夌畝鍗曟柟娉曟潵澹版槑鍜屼嬌鐢ㄤ綔鍑哄搷搴旂殑DHTML鐣岄潰緇勪歡銆傝〃鐜板湪璁稿琛ㄧ幇涓婁笅鏂?渚?
濡傦細(xì)SVG錛屾垨鐢氳嚦鍙兘妗岄潰鎴杅lash)鍙兘琚悎娉曞寲,浣嗘槸鏍囪璇█(DojoML)鍜岃剼鏈璦錛圝avascript錛夊皢涓嶆敼鍙樸傜劧鑰屾洿濂界殑錛?
DojoML
瑙ｆ瀽鍣ㄦ帴鍙楀凡鎵╁睍鐨凥TML鍜孲VG浣滀負(fù)涓涓悎娉曠殑杈撳叆錛屽茍涓斿彲浠ヨ瀹規(guī)槗鐨勫垱寤篋egradeableResponsiveApplications.
MyEc Javascript 璋冭瘯鍣ㄨ瘯棣栦釜涓篔avascript銆傚畬鏁撮泦鎴愬鎴風(fēng)Eclipse璋冭瘯鍣ㄣ傜壒寰佷富瑕佸寘鍚細(xì)
- Debug any web page containing JavaScript source or included JavaScript files, or standalone JavaScript files
- 璋冭瘯浠諱綍web欏甸潰鍖呭惈Javascript 婧愪唬鐮佹垨鍖呭惈Javascript 鏂囦歡錛屾垨鑰呭崟鐙殑Javascript鏂囦歡
- Operations: Pause, Resume, Step Into, Step Over, Step to Return, Terminate
- 鎿嶄綔錛氭殏鍋溿侀噸鏂板紑濮嬨佽繘鍏ャ佽煩鍑恒佽煩鍏ヨ繑鍥炪佺粓姝?
- Views: 瑙嗗浘
- Web Browser View (web 嫻忚鍣ㄨ鍥?
- Call Stack View聽 錛堝懠鍙爢鏍堣鍥撅級
- Variables View (鍙橀噺瑙嗗浘)
- Console View聽 錛堟帶鍒跺彴瑙嗗浘錛?/li>
- Set JavaScript breakpoints in: 璁劇疆javascript鏂偣
- JavaScript聽files (Javascript鏂囦歡)
- HTML with embedded JavaScript and linked JavaScript files 錛堝寘鍚唴緗殑javascript鍜屽叧鑱旂殑javascript鏂囦歡鐨凥TML錛?
- JSP聽files (jsp 鏂囦歡)
- Conditional breakpoints planned for MyEclipse 4.1.1 錛堜負(fù)MyEC鐨勬湁鏉′歡鐨勬柇鐐硅鍒掞級
- Integrates with Eclipse Launch Manager 錛堥泦鎴怑clipse鍙戣綆＄悊鍣級
- Quick launch from context-menu using "Debug As" (浣跨敤Debug As 榪呴熻皟鐢ㄤ笂涓嬫枃鎸夐挳)
- Launch from Eclipse Debug toolbar action 錛堜粠Eclipse 璋冭瘯宸ュ叿鏉¤涓轟腑璋冪敤錛?
- Use Launch Profile to modify launch configuration 錛堬級
- Launch JavaScript resource from project location or deployed MyEclipse web-application
Ten good practices for writing JavaScript in 2005
1. Make sure your JavaScript code is in balance with its environment
Web Standards are a three-legged stool, or without metaphors(鏆楀柣), a threesome錛堜笁浜轟竴緇勶級 of technologies that should live together in harmony錛堝拰鐫︾浉澶勶級. (X)HTML adds structure and semantics to your content, CSS is responsible for 錛堜負(fù)...璐熻矗錛塱ts presentation, and the DOM provides an interface to add behavior. You keep your Web pages flexible (or: easier to understand, maintain, restyle<鏀瑰彉鏍峰紡> and update behavior) by separating all three layers; structure and content from presentation, structure and content from behavior and presentation from behavior. To accomplish this, try to avoid inline behavior and use unobtrusive techniques instead.
涓昏琛ㄨ堪浜嗕笁縐嶆妧鏈殑緇煎悎浣跨敤錛宧tml涓虹粏鑺傜粨鏋勫拰璇硶 css涓鴻〃鐜拌礋璐?nbsp; dom鏀寔澧炲姞浜嬩歡琛屼負(fù)鐨勬帴鍙ｃ?/P>
When you attach behavior on page load, you may have to work around some known issues. First, you may encounter differences in cross-browser event handling. Second, make sure you don't overwrite existing onload handlers. Last, but not least, you may encounter a delay in the attachment of your behavior. The underlying 錛堟綔鍦ㄧ殑錛塸roblem is that a window onload event will only execute after the whole document, including all page assets like images and objects, is loaded. If your script needs to respond immediately after an element has loaded or if you work with a lot of content, a series of images or a slow server, you may be forced to look for a solution. You can either hide your content until the behavior is attached or attach the behavior via a script call after your elements are loaded, like at the end of the body element.
浠嬬粛鍦ㄩ〉闈㈠紑鍙戜腑涓昏閬囧埌鐨勯棶棰橈紒
Choose your markup wisely, so you can take full advantage of the power of the DOM.<鍏呭垎鍒╃敤dom鐨勫姏閲?gt; For example, when you use nested lists to build a navigation bar, you can use the structure of the DOM tree instead of a replicated(澶嶅埗) structure in arrays.<list dom tree> Scripting should be avoided in some cases where you can use markup or CSS to create behavior. This may sound a bit contradictory(鍙嶅), however built-in behavior enabled by (X)HTML attributes (e.g. disabling a form field or setting a max length on an input field) and CSS pseudo-classes (e.g. when building rollovers or drop downs) are regarded to be wider supported and easier to implement than using JavaScript. ToughQuiz on Quirksmode illustrates the discussion and the fine line between the uses of CSS generated content and regular markup and behavior.
In those cases where CSS currently lacks<緙轟箯> cross-browser support or is missing features for adding presentation, DOM based scripting can supplement<琛ュ厖> CSS. Presentational scripting will probably be replaced in a few years, when browsers have better CSS2.1 compliance<欏轟粠> and with the support of CSS3. Please realize that, because of the interrelationship<鐩鎬簰褰卞搷> of the different Web Standards and because both Web Standards and Web clients are constantly evolving<榪涘寲>, some good practices for using the DOM and JavaScript will change over time<闅忕潃鏃墮棿鐨勮繃鍘?gt;.
2. Create accessible<鍙悊瑙ｇ殑銆佹槗鍙楀獎鍝嶇殑> JavaScript
JavaScript is accessible when a page's navigation, content and main functionality (e.g. submitting a form) is available to your whole target audience, independent of their Web client or input device. This includes:
- People who use assistive<甯姪> technologies, like screen readers
- People who don't use a mouse for navigation
- People who have no JavaScript support (e.g. some mobile clients), have JavaScript disabled, or have partial<閮ㄥ垎鐨?gt; DOM or JavaScript support
- Machines, like search engines
The most common way to create accessible JavaScript is to use unobtrusive techniques that are mouse independent and enhance your already accessible markup with behavior. Progressive enhancement and its predecessor graceful degradation are good strategies to create Web pages that are accessible to the most common denominator, while providing a better user experience for a smaller group of people with more advanced devices or Web clients. No matter what strategy you use, make sure that you always design for multiple scenarios.
3. Create usable錛堜究浜庝嬌鐢ㄧ殑錛?JavaScript
The usability of a Web page is often determined by a good information architecture, clear and intuitive(鐩磋鐨? visual design and well designed functionality. One of the main arguments to enhance your markup using unobtrusive JavaScript is to improve the usability of a Web page by supporting these usability attributes. If you add JavaScript and don't enhance the usability of a Web page, you should rethink if you should apply it at all.
4. Create easy applicable錛堝彲閫傜敤鐨勶級 JavaScript
Unobtrusive scripting bridges the gap between 'designers' and 'coders'. There is a big group of people in today's industry that does know how to write (X)HTML and CSS but doesn't feel very comfortable with the DOM and JavaScript. Unobtrusive behavior introduced a mechanism to easily apply small portable scripts to a Web page: "Just make sure your markup looks like A, include this script B, and as a result you have a page that can do C".
Try to create small pieces of independent code. The disadvantages of a lot of existing JavaScript code libraries are that you often have to include a lot more code than you really need and that they are harder to understand and maintain if you didn't create them yourself. Because the functions in these libraries are often grouped and reused by other scripts, it often feels like they are spaghetti-coded. A library with small unobtrusive scripts has the advantage of being light-weight, easy to be understood and easy to be adjusted for more specific implementations.
Create reusable code. If you find yourself duplicating code snippets(鐗囨), create functions. If you find yourself duplicating(澶嶅埗) similar code snippets, try to abstract your code to the level that you can reuse it for multiple purposes.
Document your code well. If you work together with other people, like to share your code with others, or still want to know why you did certain things one year from now, good documentation is key.
5. Create future-proof JavaScript
Avoid browser detection, because it is almost impossible to maintain in the future. Feature testing or object detection offers a browser independent and future-proof technique to test to what extent your Web client supports JavaScript.
XHTML (if not used in backwards-compatible mode) introduces media type application/xhtml+xml (currently unsupported by Internet Explorer), which has a huge impact on how we write JavaScript code:
- The HTML DOM is case-insensitive, the XML DOM is case-sensitive (鍖哄垎澶у皬鍐?
- Elements need to be referenced in lowercase, e.g. document.getElementsByTagName("p")
- document.body is deprecated, instead reference it by id or use document.getElementsByTagName("body").item(0)
- Collections like document.images, document.applets, document.links, document.forms and document.anchors do not exist when serving XHTML as XML, instead use document.getElementsByTagName()
- innerHTML and document.write cannot be used anymore, instead use DOM methods, e.g. document.createElementNS("http://www.w3.org/1999/xhtml", "div")
If you want to keep yourself up-to-date with the latest developments, there are a lot of initiatives from different organisations that will impact the ways we use JavaScript and the DOM in the near future:
- W3C
- DOM 3 provides further XML and XPath integration
- XHTML 2 includes XML Events, which introduces a declarative way to hook up event observers via markup, and XForms, which will change the way how we add behavior to forms
- CSS3 introduces new pseudo-elements
- ECMA
- ECMAScript for XML (E4X) offers a set of programming language extensions adding native XML support to ECMAScript
- ECMAScript 4 makes ECMA based languages (like JavaScript 2 and ActionScript 2) suitable for writing modular and object-oriented applications
- Browser vendors
- Standards support, e.g. at the moment it is still a big question if Microsoft will ever fully support existing Web Standards and is going to support future standards
- The addition of proprietary methods and attributes, e.g. innerHTML, Microsoft.XMLHTTP and XMLHttpRequest
- Collaborations like the WHAT WG aimed to create new standards in shorter timeframes, e.g. the submission of Web Forms 2 to become a W3C recommendation and Web Applications, which in the future may standardise XMLHttpRequest
6. Know JavaScript's weaknesses(寮辯偣), limitations錛堥檺鍒訛級 and bugs
Although JavaScript is generally well supported by most modern Web clients, support still remains its biggest weakness. Because from the first days of the Web users were often harassed(鐤插︾殑) by all kinds of annoying(璁ㄥ帉鐨? behavior, browser makers decided to make it easy to switch JavaScript off (Windows XP Service Pack 2 even disables some JavaScript by default, because it regards it as active scripting). If you compare JavaScript with its little stepbrother ActionScript (which is supported when the Flash plug-in is installed and cannot be switched off), you will find that the main difference is that you can rely on its behavior to accomplish certain tasks. Because it is just too easy to switch JavaScript off, simple tasks like form validation always need to be duplicated at the server side. It will be for this reason that in the future most client-side form validation will be replaced by markup and 'built-in behavior'.
As mentioned earlier, the onload event handler is insufficient to get the best out of unobtrusive techniques. I hope that the people of the W3C will respond to this feedback from the JavaScript community and add new handlers like onElementLoad and onDOMLoad to future DOM specifications.
The JavaScript implementations of Internet Explorer and Safari suffer from memory leaks when using circular references like closures. When using circular references, make sure you remove event handlers when a page is unloaded.
7. Often there is more than one good solution
JavaScript is a very flexible language and as a result you often have multiple ways of doing things. You could choose for either a procedural(紼嬪簭涓? or an object oriented way of coding. For your unobtrusive behavior you can either use custom attributes or use class attributes as triggers to fully control the behavior of your site. Flexibility implies that you have to make certain choices, however often one solution is not necessarily better or worse than another. Base your decisions on the context in which you have to use your scripts and your own philosophy or taste and try to use a consistent coding style.
8. Write your own scripts or reuse code from trusted places
Currently a lot of outdated(榪囨湡鐨? and badly written code is available on the Internet. Many scripts are plagued by browser detection, are using proprietary features that don't work cross-browser, are inaccessible or are not separating behavior from structure, because they rely on inline event handlers and scripts. It seems that Web Standards, Web clients and the practice of writing good JavaScript have evolved so quickly in the past two years, that it is hard to keep up with the latest good practices. This on its turn makes it hard to reuse code from others or reuse code you wrote yourself a year ago. Because some parts of older scripts may still contain valid code constructs, it is best to review them and rewrite the parts that don't suffice anymore. You will probably often find that a complete rewrite will do best.
So how do less experienced DOM and JavaScript users tell the difference between good and bad code on the Internet? There are some experts on the Internet that advocate modern ways of scripting and there are communities that discuss and rate new scripts and techniques. Some examples are:
- DHTML & CSS Blog: Stylish Scripting
- A List Apart
- QuirksMode
- Simon Willison
- Stuart Langridge
- Christian Heilmann
- Brainjar
- Gazingus
DHTML Utopia: Modern Web Design Using JavaScript & DOM is the first title of a new range of books focusing on the application of modern JavaScript and unobtrusive scripting techniques.
9. Optimize your JavaScript code for performance
Optimize your scripts for both download speed and execution speed. <涓嬭澆閫熷害鍜屾墽琛岄熷害>Some tips:
- Avoid fat code libraries and make sure your scripts stay lean and mean (or: small, independent and straightforward)
- Write efficient code and avoid constructs that execute slow
- Keep developer versions of your scripts that include full comments and use a compression<鍘嬬緝> tool (like JavaScript cruncher or JavaScript Crunchinator) to strip out all comments and white-spaces to create a version for deployment.
10. Use tools to optimize your work process
A selection of tools that make life much easier:
- Mozilla or Firefox browser
- Includes the good old Netscape JavaScript console by default (Tools > Web Development > JavaScript Console for Mozilla and Tools > JavaScript Console for Firefox), e.g. to view errors and warnings that make sense
- The Web Developer Toolbar extension, e.g. to quickly enable or disable your scripts
- The Mozilla DOM Inspector and the Firefox DOM Inspector extension, to inspect and edit the live DOM of any Web document
- Venkman, the JavaScript debugger (the Venkman extension for Firefox)
- JSDoc, a tool that parses inline documentation in JavaScript source files, and produces an HTML summary
- JSLint, a JavaScript verifier to check for syntax and programming errors.
漏 Copyright 2004-2006 Bobby van der Sluis All rights reserved.
userAgent
The string that the browser sends in its USER-AGENT HTTP header.This property typically contains all the information in both appName and appVersion.
eg.
this.isIE = navigator.userAgent.toLowerCase().indexOf("msie") >= 0;
This provides a new method to the core class Function. The method,called bindAsEventListener(),is used to do bind methods to event handlers.
榪欎負(fù)鏍稿績class 鍑芥暟鏀寔浜嗕竴涓柊鐨勬柟娉曘傝繖涓柟娉曞彨bindAsEventListener(),鏄敤鏉ョ粦瀹氭柟娉曠粰浜嬩歡澶勭悊鍣ㄧ殑銆?BR>var obj = new SomeClass();
var closure = obj.someMethod.bindAsEventListener(this);
element.onclick = closure;