Talk about project combat from JavaScript language itself
dulao5 2005-1-15
As Ajax has warmed up, JavaScript has become more and more important to people. Importantly, Ajax has brought about changes in the architecture of the Web software to some extent, with more and more functions being assigned to the client, and JavaScript subprojects becoming larger. How to use JavaScript more efficiently, how to organize JavaScript more scientifically, and how to ensure project progress more smoothly? I would like to talk a little about my experience.
One. Developers need to seriously learn the JavaScript language itself
Because JavaScript is "the most misunderstood language in the world," most people don't fully understand JavaScript syntax, but write JavaScript code in their own way with keywords that look like C or Java. In fact, JavaScript is a very unique language, and C++/java has a very big difference, in order to use JavaScript to bigger projects, developers must be honest learning JavaScript syntax. After mastering the grammar, we don't think of delete as freeing the memory object to worry about whether the parameter pass is a value pass or a reference pass. It is possible to write a well-formed JavaScript program that really understands JavaScript based on the prototype OO approach.
The "JavaScript Authority Guide" is the most appropriate book, solemnly recommended. Another ECMA262 document can be used as a reference. The online version of the JScript manual chm is easy to use, but this is a Microsoft JScript implementation, and standard JavaScript slightly different, use should pay attention to the above footnote information. On the JavaScript prototype and OO, there are many articles on the web, there is no more to say.
Two. Good code comes from a good design
Only the design is good, the code will write beautifully. Now that JavaScript subprojects are not "scraps" or "stragglers" in previous Web projects, JavaScript can be very complex within larger AJAX projects, and the AJAX asynchronous model differs from previous sequential programming. So it is recommended to do the design before JavaScript first. It is recommended to use use case-driven approach to analyze the use case in order to consider all possible page interaction processes globally, draw an interaction diagram between some objects within a page, analyze the state of some data objects, and make a fine JavaScript design.
Three. Use design patterns to reuse design experience in other areas
If JavaScript is very complex, consider using some patterns. I think most of the developers who do JavaScript are not "javascript prep" backgrounds: Mastering the language nature of JavaScript allows us to reuse our experience in other areas. Use a JavaScript framework or AJAX framework, use a single case pattern to do a global buffer pool, or use observer mode to separate interface objects from data Objects, use command mode to implement user's operation queues, and so on.
Four. Tips for debugging code
JavaScript code is not very good to debug, this is due to:
- The average developer is not very proficient in the JavaScript language itself. Which is mentioned above.
- Web projects contain more factors and increase complexity. Server-side scripts, templates, HTML, JS and many other links may increase the difficulty of debugging.
- There is a compatibility problem with the browser. There may be a difference in the details of IE, Mozilla, opera and other browsers.
- Lack of tools. While Mozilla's Jsdebugger is very handy (and there are bugs, such as some problems with the debugger in eval), debugging tools in other browser environments are not. Ms System with the Script Debug Tool debug Local code can also directly debug the site JS code poor performance. Opera did not find any other debugging tools except the JavaScript console.
Here I recommend a few debugging tips:
- Use Mozilla Firefox's Jsdebugger plugin. This I no longer say, the most classic JS debugging tools. Debugging the JavaScript on the remote site online is great.
- Isolate the problem, create local HTML files and JS files, and Use the MS Script Debug Debugging tool to Debug. If the JS module is more independent, you can use this tool. If you write an HTA project, the tool is certainly preferred.
- HttpWatch This is an IE plug-in, very useful, able to monitor any HTTP session in IE, and can see the original HTTP session. This tool lets you know if your program has a session with the server, and what the parameters and what data is returned.
- Create a textarea for debugging within a Web page
You can create a textarea in the Web page to accept the JS statement you want to run, and then add a button to use the JS eval function to execute the code you entered.
This is a great way to debug online, and write down the values of the objects in the code output page after a page error. It is recommended to write some dump tool functions in conjunction with better results.
I like this way very much, you can always use the switch to open the hidden textarea in the page for debugging, feel like a server to connect to the terminal, and then use the shell can do anything: Functions can be redefined here, any element in the interface can be invoked, any function of any object will be called, and any run-time value you need will be output.
- Using exceptions (Exception) and assertions (assert)
Using the Try{}catch (e) {} structure will not only mask error messages, but also make the interface friendlier. Our programs can use exceptions and throw exceptions to build a better error-handling mechanism.
There is such a story, I write this code when I use the String.localecompare function:
var iRe = Str1.localecompare (STR2);
Switch (iRe) {
0:return .....
1:return .....
-1:return .....
Defalut:throw "Error:localecompare return to other value"
}
When I finished, I forgot, I did not expect my colleagues to use Firefox under Linux, the exception was thrown, and then we know: Linux Firefox localecompare return not only 0/1/-1, but return a specific value.
This exception is thrown effectively to detect the imperfection of the code.
Firefox under the exception dump can get a more detailed call stack information, which is very good. IE's exception information is not so detailed.
Exceptions and assertions can also be combined into a very effective debugging tool.
Assertions (assert) are a very effective debugging tool in other languages, and often appear in this form:
ASSERT (< conditions >);
When the program is in debug state and the condition is false, the system aborts and reports the assertion. Since assertions are defined by ourselves, we can easily determine where the error occurred and then find the bug.
The JavaScript language does not provide macros or assert, so we can simulate
if (_is_debug) assert = function (expression, strlable) {
if (!expression) throw Error (strlable);
}
else assert = function () {};//_is_debug is a global variable
This enables the program to throw an exception in debug mode when the "impossible" occurs, ignoring the release version.
This can output the current stack of call information, to make up for the above mentioned in IE in the exception object without stack information defects:
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;
}
This article only discusses the development of JavaScript in web development, especially in Ajax, and focuses on how to better use "pure JavaScript". There are many other aspects of web development, such as XML and DOM, which are actually related to JavaScript, but this article is not covered, please forgive me. Welcome all my friends to comment on my discussion.
--
-------------------------------------------------------------------
Dulao5 to the