文档对象模型和动态HTML外文翻译

《文档对象模型和动态HTML外文翻译》由会员分享，可在线阅读，更多相关《文档对象模型和动态HTML外文翻译（8页珍藏版）》请在毕设资料网上搜索。

1、 河北建筑工程学院 毕业设计（论文）外文资料翻译 系别： 计算机系 专业： 计算机科学与技术 班级： 计 092 班 姓名： 孙全华 学号： 2009309216 外文出处： 导师提供 指导教师评语： 签字： 年 月 日 英语原文： Document Object Model and Dynamic HTML The term Dynamic HTML,often abbreviated DHTML,refers to the technique of making Web pages dynamic by client-side scripting to manipulate the doc

2、ument content and presentation.Web pages can be made more lively,dynamic,or interactive by DHTML techniques. With DHTML,you can prescribe actions triggered by browser events to make the page more lively and responsive.Such actions may alter the content and appearance of any parts of the page.The cha

3、nges are fast and efficient because they are made by the browser without having to network with any servers.Typically,the client-side scripting is written in JavaScript and basic techniques for making Web pages dynamic. Contrary to what the name may suggest,DHTML is not a markup language or a softwa

4、re tool.It is a technique to make Web pages dynamic through client-side programming.In the past,DHTML relied on browser-and vendor-specific features.Making such pages work for all browsers requires much effort,testing,and unnecessarily long programs. Standardization efforts at W3C and elsewhere are

5、making it possible to write standard-based DHTML that works for all compliant browsers.Standard-based DHTML involves three aspects. 1.JavaScriptfor cross-browser scripting(Chapter9) 2.Cascading Style Sheets(CSS)for style and presentation control (Chapter6) 3.Document Object Model(DOM)for a uniform p

6、rogramming interface to access and manipulate the Web page as a document When these three aspects are combined,you get the ability to program changes in Web pages in reaction to user-or browser-generated events.Therefore,you can make HTML pages more dynamic. Popular with Web developers,supported by

7、all major browsers,and standardized,JavaScript provides the ability to program browser actions in response to events.To have true cross-platform DHTML,we still need a uniform way for JavaScript to access and manipulate Web documents.This brings us to the DOM. 10.1 What is DOM? The objective of unit

8、and integration testing was to ensure that the code implemented the design properly；that is,that the programmers wrote code to do what the designers intended.In system testing,we have a very different objective:to ensure that the system does what the customer wants it to do.To understand how to meet

9、 this objective,we first must understand where faults in the system come from. Recall that a software fault causes a failure only when accompanied by the right conditions.That is,a fault may exist in the code,but if the code is never executed,or if the code is not executed long enough or in the appr

10、opriate configuration to cause a problem,we may never see the software fail.Because testing cannot exercise every possible condition,we keep as our goal the discovery of faults,hoping that in the process we eliminate all faults that might lead to failures during actual system usage. Software faults

11、can be inserted in a requirement,design,or code component,or in the documentation,at any point during development or maintenance.Figure 9.1 illustrates the likely causes of faults in each development activity.Although we would like to find correct faults as early as possible,system testing acknowled

12、ges that faults may still be present after integration testing. Faults can be introduced to the system early in development or late,such as when correcting a newly discovered fault.For example,defective software can result from faults in the requirements.Whether a requirement was ambiguous because t

13、he customer was unsure of a need or because we misinterpreted the customers meaning,the result is the same:a system that does not work the way the customer wants in to work. The same kind of communication mishaps can occur during system design.We may misinterpret a requirement and write an incorrect

14、 design specification.Or we understand the requirement but may word the specification so poorly that those who subsequently read it and use the design misunderstand it.Similarly,we may make assumptions about characteristics and relationships that are not shared by the other readers of the design. Si

15、milar events can lead to program design faults.Misinterpretations are common when the system design is translated into lower-level description for program design specifications.Programmers are several levels removed from the initial discussions with customers about system goals and functionality.Hav

16、ing responsibility for one “tree” but not the “forest,” programmers cannot be expected to spot design faults that have been perpetuated through the first steps of the development cycle.For this reason,requirements and design reviews are essential to ensuring the quality of the resulting system. The

17、programmers and designers on our development team may also fail to use the proper syntax and semantics for recording their work.A compiler or assembler can catch some fo these faults before a program is run,but they will not find faults when the form of a statement is correct but does not match the

18、intention of the programmer or designer. Once program component testing begins,faults may be added unintentionally in making changes to correct other problems.These faults are often very difficult to detect,because they may appear only when certain functions are exercised,or only under certain condi

19、tions.If those functions have already been tested when a new fault is inadvertently added,the new fault may not be noticed until much later,when its source may not be clear.This situation is likely to happen if we are reusing code from other applications,and we modify it to suit our current needs.Th

20、e nuances of the codes design may not be apparent,and our changes may in fact do more damage than good. For example,suppose you are testing components A,B and C.You test each separately.When you test all three together,you find that A passes a parameter to C incorrectly.In repairing A,you make sure that the parameter pass is now correct,but you add code that sets a pointer incorrectly.Because you may not go back and test A independently again,you may not find evidence of the new fault until much later in