2848.C城市公交查詢系統(tǒng)畢業(yè)設(shè)計(jì) 外文翻譯

1、 外文翻譯城市公交查詢系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)學(xué) 生 姓 名： 指導(dǎo)教師： 副教授 合作指導(dǎo)教師： 專業(yè)名稱： 計(jì)算機(jī)科學(xué)與技術(shù) 所在學(xué)院： 水產(chǎn)學(xué)院 2009 年6月原文摘自：lvar jacobson.object-oriented software engineering.第1版.北京：人民郵電出版社，2005.10外文資料原文asp.net page object model:summary: learn about the eventing model built around asp.net web pages and the various stages that a web page

2、experiences on its way to html. the asp.net http run time governs the pipeline of objects that transform the requested url into a living instance of a page class first, and into plain html text next. discover the events that characterize the lifecycle of a page and how control and page authors can i

3、ntervene to alter the standard behavior. (6 printed pages)introduction: each request for a microsoft asp.net page that hits microsoft internet information services (iis) is handed over to the asp.net http pipeline. the http pipeline is a chain of managed objects that sequentially process the request

4、 and make the transition from a url to plain html text happen. the entry point of the http pipeline is the httpruntime class. the asp.net infrastructure creates one instance of this class per each appdomain hosted within the worker process (remember that the worker process maintains one distinct app

5、domain per each asp.net application currently running).the httpruntime class picks up an httpapplication object from an internal pool and sets it to work on the request. the main task accomplished by the http application manager is finding out the class that will actually handle the request. when th

6、e request is for an .aspx resource, the handler is a page handlernamely, an instance of a class that inherits from page. the association between types of resources and types of handlers is stored in the configuration file of the application. more exactly, the default set of mappings is defined in th

7、e section of the machine.config file. however, the application can customize the list of its own http handlers in the local web.config file. the line below illustrates the code that defines the http handler for .aspx resources.an extension can be associated with a handler class, or more in general,

8、with a handler factory class. in all cases, the httpapplication object in charge for the request gets an object that implements the ihttphandler interface. if the association resource/class is resolved in terms of a http handler, then the returned class will implement the interface directly. if the

9、resource is bound to a handler factory, an extra step is necessary. a handler factory class implements the ihttphandlerfactory interface whose gethandler method will return an ihttphandler-based object.how can the http run time close the circle and process the page request? the ihttphandler interfac

10、e features the processrequest method. by calling this method on the object that represents the requested page, the asp.net infrastructure starts the process that will generate the output for the browser.the real page classthe type of the http handler for a particular page depends on the url. the fir

11、st time the url is invoked, a new class is composed and dynamically compiled to an assembly. the source code of the class is the outcome of a parsing process that examines the .aspx sources. the class is defined as part of the namespace asp and is given a name that mimics the original url. for examp

12、le, if the url endpoint is page.aspx, the name of the class is asp.page_aspx. the class name, though, can be programmatically controlled by setting the classname attribute in the page directive.the base class for the http handler is page. this class defines the minimum set of methods and properties

13、shared by all page handlers. the page class implements the ihttphandler interface.under a couple of circumstances, the base class for the actual handler is not page but a different class. this happens, for example, if code-behind is used. code-behind is a development technique that insulates the cod

14、e necessary to a page into a separate c# or microsoft visual basic.net class. the code of a page is the set of event handlers and helper methods that actually create the behavior of the page. this code can be defined inline using the tag or placed in an external classthe code-behind class. a code-be

15、hind class is a class that inherits from page and specializes it with extra methods. when specified, the code-behind class is used as the base class for the http handler.the other situation in which the http handler is not based on page is when the configuration file of the application contains a re

16、definition for the pagebasetype attribute in the section.the pagebasetype attribute indicates the type and the assembly that contains the base class for page handlers. derived from page, this class can automatically endow handlers with a custom and extended set of methods and properties.the page lif

17、ecycleonce the http page handler class is fully identified, the asp.net run time calls the handlers processrequest method to process the request. normally, there is no need to change the implementation of the method as it is provided by the page class.this implementation begins by calling the method

18、 frameworkinitialize, which builds the controls tree for the page. the method is a protected and virtual member of the templatecontrol classthe class from which page itself derives. any dynamically generated handler for an .aspx resource overrides frameworkinitialize. in this method, the whole contr

19、ol tree for the page is built.next, processrequest makes the page transit various phases: initialization, loading of view state information and postback data, loading of the pages user code and execution of postback server-side events. after that, the page enters in rendering mode: the updated view

20、state is collected; the html code is generated and then sent to the output console. finally, the page is unloaded and the request is considered completely served.during the various phases, the page fires a few events that web controls and user-defined code can intercept and handle. some of these eve

21、nts are specific for embedded controls and subsequently cant be handled at the level of the .aspx code.a page that wants to handle a certain event should explicitly register an appropriate handler. however, for backward compatibility with the earlier visual basic programming style, asp.net also supp

22、orts a form of implicit event hooking. by default, the page tries to match special method names with events; if a match is found, the method is considered a handler for the event. asp.net provides special recognition of six method names. they are page_init, page_load, page_databind, page_prerender,

23、and page_unload. these methods are treated as handlers for the corresponding events exposed by the page class. the http run time will automatically bind these methods to page events saving developers from having to write the necessary glue code. for example, the method named page_load is wired to th

24、e pages load event as if the following code was written.this.load += new eventhandler(this.page_load);the automatic recognition of special names is a behavior under the control of the autoeventwireup attribute of the page directive. if the attribute is set to false, any applications that wish to han

25、dle an event need to connect explicitly to the page event. pages that dont use automatic event wire-up will get a slight performance boost by not having(51-aspx) to do the extra work of matching names and events. you should note that all microsoft visual studio .net projects are created with the aut

26、oeventwireup attribute disabled. however, the default setting for the attribute is true, meaning that methods such as page_load are recognized and bound to the associated event.the execution of a page consists of a sequence of stages listed in the following table and is characterized by application-

27、level events and/or protected, overridable methods.table 1. key events in the life of an asp.net pagestagepage eventoverridable methodpage initializationinitview stateloadingloadviewstatepostback data processingloadpostdata method in any control that implements the ipostbackdatahandler interfacepage

28、 loadingloadpostback change notificationraise51posaspxtdatachangedevent method in any control that implements the ipostbackdatahandler interfacepostback event handlingany postback event defined by controlsraisepostbackevent method in any control that implements the ipostbackeventhandler interface pa

29、ge pre-rendering phaseprerenderview state savingsaveviewstatepage renderingrenderpage unloadingunloadsome of the stages listed above are not visible at the page level and affect only authors of server controls and developers who happen to create a class derived from page. init, load, prerender, unlo

30、ad, plus all postback events defined by embedded controls are the only signals of life that a page sends to the external world.stages of executionthe first stage in the page lifecycle is the initialization. this stage is characterized by the init event, which fires to the application after the pages

31、 control tree has been successfully created. in other words, when the init event arrives, all the controls statically declared in the .aspx source file have been instantiated and hold their default values. controls can hook up the init event to initialize any settings that will be needed during the

32、lifetime of the incoming web request. for example, at this time controls can load external template files or set up the handler for the events. you should notice that no view state information is available for use yet.immediately after initialization, the page framework loads the view state for the

33、page. the view state is a collection of name/value pairs, where controls and the page itself store any information that must be persistent across web requests. the view state represents the call context of the page. typically, it contains the state of the controls the last time the page was processe

34、d on the server. the view state is empty the first time the page is requested in the session. by default, the view state is stored in a hidden field silently added to the page. the name of this field is _viewstate. by overriding the loadviewstate methoda protected overridable method on the control c

35、lasscomponent developers can control how the view state is restored and how its contents are mapped to the internal state.methods like loadpagestatefrompersistencemedium and its counterpart savepagestatetopersistencemedium can be used to load and save the view state to an alternative storage mediumf

36、or example, session, databases, or a server-side file. unlike loadviewstate, the aforementioned methods are available only in classes derived from page.once the view state has been restored, the controls in the page tree are in the same state they were the last time the page was rendered to the brow

37、ser. the next step consists of updating their state to incorporate client-side changes. the postback data-processing stage gives controls a chance to update their state so that it accurately reflects the state of the corresponding html element on the client. for example, a server textbox control has

38、 its html counterpart in an element. in the postback data stage, the textbox control will retrieve the current value of tag and use it to refresh its internal state. each control is responsible for extracting values from posted data and updating some of its properties. the textbox control will updat

39、e its text property whereas the checkbox control will refresh its checked property. the match between a server control and a html element is found on the id of both.at the end of the postback data processing stage, all controls in the page reflect the previous state updated with changes entered on t

40、he client. at this point, the load event is fired to the page.there might be controls in the page that need to accomplish certain tasks if a sensitive property is modified across two different requests. for example, if the text of a textbox control is modified on the client, the control fires the te

41、xtchanged event. each control can take the decision to fire an appropriate event if one or more of its properties are modified with the values coming from the client. controls for which these changes are critical implement the ipostbackdatahandler interface, whose loadpostdata method is invoked imme

42、diately after the load event. by coding the loadpostdata method, a control verifies if any critical change has occurred since last request and fires its own change event.the key event in the lifecycle of a page is when it is called to execute the server-side code associated with an event triggered o

43、n the client. when the user clicks a button, the page posts back. the collection of posted values contains the id of the button that started the whole operation. if the control is known to implement the ipostbackeventhandler interface (buttons and link buttons will do), the page framework calls the

44、raisepostbackevent method. what this method does depends on the type of the control. with regard to buttons and link buttons, the method looks up for a click event handler and runs the associated delegate.after handling the postback event, the page prepares for rendering. this stage is signaled by t

45、he pretender event. this is a good time for controls to perform any last minute update operations that need to take place immediately before the view state is saved and the output rendered. the next state is saveviewstate, in which all controls and the page itself are invited to flush the contents o

46、f their own viewstate collection. the resultant view state is then serialized, hashed, base64 encoded, and associated with the _viewstate hidden field.the rendering mechanism of individual controls can be altered by overriding the render method. the method takes an html writer object and uses it to

47、accumulate all html text to be generated for the control. the default implementation of the render method for the page class consists of a recursive call to all constituent controls. for each control the page calls the render method and caches the html output.the final sign of life of a page is the

48、unload event that arrives just before the page object is dismissed. in this event you should release any critical resource you might have (for example, files, graphical objects, database connections).finally, after this event the browser receives the http response packet and displays the page.summar

49、ythe asp.net page object model is particularly innovative because of the eventing mechanism. a web page is composed of controls that both produce a rich html-based user interface and interact with the user through events. setting up an eventing model in the context of web applications is challenging

50、. its amazing to see that client-side generated events are resolved with server-side code, and the output of this is visible as the same html page, only properly modified.to make sense of this model it is important to understand the various stages in the page lifecycle and how the page object is ins

51、tantiated and used by the http run time.譯成中文：asp.net 頁(yè)面對(duì)象模型：摘要：了解圍繞 asp.net web 頁(yè)構(gòu)建的事件模型，以及一個(gè) web 頁(yè)面在其轉(zhuǎn)變?yōu)?html 的歷程中的各個(gè)階段。asp.net http 運(yùn)行時(shí)控制對(duì)象管線，對(duì)象管線首先將所請(qǐng)求的 url 轉(zhuǎn)換為一個(gè)頁(yè)面類的活動(dòng)實(shí)例，然后將其轉(zhuǎn)換為普通 html 文本。本文將探討一個(gè)頁(yè)面的生存周期中的各個(gè)特征事件，并了解控件和頁(yè)面編寫者如何介入其中以改變其標(biāo)準(zhǔn)行為。簡(jiǎn)介：microsoft internet 信息服務(wù) (iis) 所收到的對(duì)某 microsoft asp.net 頁(yè)

52、面的每個(gè)請(qǐng)求都被移交給 asp.net http 管線。http 管線由一系列托管對(duì)象組成，這些對(duì)象按順序處理該請(qǐng)求，并完成從 url 到普通 html 文本的轉(zhuǎn)換。http 管線的入口點(diǎn)是 httpruntime 類。asp.net 基礎(chǔ)結(jié)構(gòu)為輔助進(jìn)程中所承載的每個(gè) appdomain 創(chuàng)建此類的一個(gè)實(shí)例（請(qǐng)注意，該輔助進(jìn)程為當(dāng)前正在運(yùn)行的每個(gè) asp.net 應(yīng)用程序維護(hù)一個(gè)不同的 appdomain）。httpruntime 類從內(nèi)部池中選取一個(gè) httpapplication 對(duì)象，并讓其處理該請(qǐng)求。http 應(yīng)用程序管理器所完成的主要任務(wù)就是找出將實(shí)際處理該請(qǐng)求的類。如果請(qǐng)求 .as

53、px 資源，則處理程序就是一個(gè)頁(yè)面處理程序 即某個(gè)繼承自 page 的類的一個(gè)實(shí)例。資源類型和處理程序類型之間的關(guān)聯(lián)關(guān)系存儲(chǔ)于該應(yīng)用程序的配置文件中。更準(zhǔn)確地說(shuō)，在 machine.config 文件的 部分中定義默認(rèn)的一組映射關(guān)系。然而，應(yīng)用程序也可以在本地的 web.config 文件中自定義自己的 http 處理程序列表。下面的程序行舉例說(shuō)明了定義用于 .aspx 資源的 http 處理程序的代碼。擴(kuò)展名可關(guān)聯(lián)到一個(gè)處理程序類，或者更普遍地關(guān)聯(lián)到一個(gè)處理程序工廠 (handler factory) 類。在所有情況下，負(fù)責(zé)處理請(qǐng)求的 httpapplication 對(duì)象都會(huì)獲得一個(gè)實(shí)現(xiàn) i

54、httphandler 接口的對(duì)象。如果根據(jù) http 處理程序來(lái)解析關(guān)聯(lián)資源/類，那么所返回的類將直接實(shí)現(xiàn)該接口。如果資源綁定到處理程序工廠，則需要另外一個(gè)步驟。處理程序工廠類實(shí)現(xiàn) ihttphandlerfactory 接口，而該接口的 gethandler 方法返回一個(gè)基于 ihttphandler 的對(duì)象。http 運(yùn)行時(shí)如何能完成整個(gè)循環(huán)并處理頁(yè)面請(qǐng)求呢？ihttphandler 接口特別提供了 processrequest 方法。通過(guò)對(duì)代表所請(qǐng)求頁(yè)面的對(duì)象調(diào)用此方法，asp.net 基礎(chǔ)結(jié)構(gòu)啟動(dòng)相應(yīng)過(guò)程，從而針對(duì)瀏覽器生成輸出。真正的 page 類特定頁(yè)面的 http 處理程序類型

55、取決于 url。當(dāng)首次調(diào)用 url 時(shí)，將構(gòu)建一個(gè)新類并將該類動(dòng)態(tài)地編譯成一個(gè)程序集。用于檢查 .aspx 來(lái)源的語(yǔ)法分析過(guò)程的輸出結(jié)果就是該類的源代碼。該類被定義為 asp 命名空間的一部分，并被賦予一個(gè)與原始 url 相似的名稱。例如，如果 url 終結(jié)點(diǎn)是 page.aspx，則類名稱為 asp.page_aspx。但是，也可通過(guò)編程設(shè)置 page 指令的 classname 屬性來(lái)控制類的名稱。http 處理程序的基類是 page。此類定義了所有頁(yè)面處理程序所共享的方法和屬性的最小集合。page 類中實(shí)現(xiàn) ihttphandler 接口。在某些情況下，實(shí)際處理程序的基類并非 page，

56、而是一個(gè)不同的類。例如，如果使用了代碼隱藏，就會(huì)出現(xiàn)這種情況。代碼隱藏是一種開發(fā)方法，它將頁(yè)面所需的代碼封裝到一個(gè)單獨(dú)的 c# 或 microsoft visual basic.net 類中。頁(yè)面的代碼就是一組事件處理程序和幫助器方法，用以實(shí)際創(chuàng)建該頁(yè)面的行為。可以利用 標(biāo)記將這種代碼定義為內(nèi)聯(lián)代碼，或者也可將其放到一個(gè)外部類 代碼隱藏類中。代碼隱藏類是一種繼承自 page 的類，但這種類具有一些額外的方法因而比較特殊。如果指定，代碼隱藏類就用作 http 處理程序的基類。還有一種情況，即當(dāng)應(yīng)用程序配置文件的 部分中重新定義了 pagebasetype 屬性時(shí)，http 處理程序也不是基于 p

57、age 的。pagebasetype 屬性指出了包含頁(yè)面處理程序的基類的類型以及程序集。派生自 page 的這個(gè)類可自動(dòng)給處理程序賦予一組自定義和擴(kuò)展的方法和屬性。頁(yè)面生存周期一旦完全確定 http 頁(yè)面處理程序類，asp.net 運(yùn)行時(shí)就調(diào)用該處理程序的 processrequest 方法以處理請(qǐng)求。通常情況下，無(wú)需更改此方法的實(shí)現(xiàn)方式，因?yàn)樗怯?page 類提供的。此實(shí)現(xiàn)方法一開始就調(diào)用 frameworkinitialize 方法，以此建立頁(yè)面的控件樹。此方法是 templatecontrol 類（page 類本身就是從該類派生出來(lái)的）的一個(gè)受保護(hù)的虛擬成員。任何針對(duì) .aspx 資源而動(dòng)態(tài)生成的處理程序都重寫 frameworkinitialize。在此方法中，該頁(yè)面的完整控件樹得以構(gòu)建。接下來(lái)，processrequest 使該頁(yè)面經(jīng)歷若干階段：初始化，加載視圖狀態(tài)信息和回發(fā)數(shù)據(jù)，加載頁(yè)面的用戶代碼并執(zhí)行回發(fā)服務(wù)器端事件。隨后，該頁(yè)面進(jìn)入呈現(xiàn)模式：收集更新后的視圖狀態(tài)；生成 htm