《毕业论文外文翻译--文档对象模型和动态HTML》由会员分享，可在线阅读，更多相关《毕业论文外文翻译--文档对象模型和动态HTML（8页珍藏版）》请在金锄头文库上搜索。
1、 河北建筑工程学院毕业设计（论文）外文资料翻译毕业设计（论文）外文资料翻译系别：系别： 计算机系 专业：专业： 计算机科学与技术 班级：班级： 计 092 班 姓名：姓名： 学号：学号： 2009309216 外外文文出出处处： 导师提供 指导教师评语：签字： 年 月 日英语原文：Document Object Model and Dynamic HTMLThe term Dynamic HTML,often abbreviated DHTML,refers to the technique of making Web pages dynamic by client-side scriptin
2、g to manipulate the document 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 pa
3、rts of the page.The changes 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 mark
4、up language or a software 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
5、 W3C and elsewhere are 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 Mode
6、l(DOM)for a uniform programming interface to access and manipulate the Web page as a documentWhen 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 devel
7、opers,supported by 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
8、objective of unit 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 unde
9、rstand how to meet 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 eno
10、ugh or in the appropriate 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
11、.Software faults 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
12、testing acknowledges 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 amb
13、iguous because the 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 wri
14、te an incorrect 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
15、 the design.Similar 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 fun
16、ctionality.Having 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 sy
