基于java離散數(shù)學(xué)課程題庫管理系統(tǒng)設(shè)計

基于java離散數(shù)學(xué)課程題庫管理系統(tǒng)設(shè)計,基于,java,離散,數(shù)學(xué)課程,題庫,管理,系統(tǒng),設(shè)計 畢 業(yè) 設(shè) 計（論 文）外 文 參 考 資 料 及 譯 文 譯文題目： Overview of JSP Technology 　　　　　 JSP技術(shù)概述 學(xué)生姓名： 專　　業(yè)： 所在學(xué)院： 指導(dǎo)教師： 職　　稱： 2016年 2月 18 日 Overview of JSP Technology Benefits of JSP JSP pages are translated into servlets. So, fundamentally, any task JSP pages can perform could also be accomplished by servlets. However, this underlying equivalence does not mean that servlets and JSP pages are equally appropriate in all scenarios. The issue is not the power of the technology, it is the convenience, productivity, and maintainability of one or the other. After all, anything you can do on a particular computer platform in the Java programming language you could also do in assembly language. But it still matters which you choose. JSP provides the following benefits over servlets alone: ? It is easier to write and maintain the HTML. Your static code is ordinary HTML: no extra backslashes, no double quotes, and no lurking Java syntax. ? You can use standard Web-site development tools. Even HTML tools that know nothing about JSP can be used because they simply ignore the JSP tags. ? You can divide up your development team. The Java programmers can work on the dynamic code. The Web developers can concentrate on the presentation layer. On large projects, this division is very important. Depending on the size of your team and the complexity of your project, you can enforce a weaker or stronger separation between the static HTML and the dynamic content. Now, this discussion is not to say that you should stop using servlets and use only JSP instead. By no means. Almost all projects will use both. For some requests in your project, you will use servlets. For others, you will use JSP. For still others, you will combine them with the MVC architecture . You want the appropriate tool for the job, and servlets, by themselves, do not complete your toolkit. Advantages of JSP Over Competing Technologies A number of years ago, Marty was invited to attend a small 20-person industry roundtable discussion on software technology. Sitting in the seat next to Marty was James Gosling, inventor of the Java programming language. Sitting several seats away was a high-level manager from a very large software company in Redmond, Washington. During the discussion, the moderator brought up the subject of Jini, which at that time was a new Java technology. The moderator asked the manager what he thought of it, and the manager responded that it was too early to tell, but that it seemed to be an excellent idea. He went on to say that they would keep an eye on it, and if it seemed to be catching on, they would follow his company's usual "embrace and extend" strategy. At this point, Gosling lightheartedly interjected "You mean disgrace and distend." Now, the grievance that Gosling was airing was that he felt that this company would take technology from other companies and suborn it for their own purposes. But guess what? The shoe is on the other foot here. The Java community did not invent the idea of designing pages as a mixture of static HTML and dynamic code marked with special tags. For example, ColdFusion did it years earlier. Even ASP (a product from the very software company of the aforementioned manager) popularized this approach before JSP came along and decided to jump on the bandwagon. In fact, JSP not only adopted the general idea, it even used many of the same special tags as ASP did. So, the question becomes: why use JSP instead of one of these other technologies? Our first response is that we are not arguing that everyone should. Several of those other technologies are quite good and are reasonable options in some situations. In other situations, however, JSP is clearly better. Here are a few of the reasons. Versus .NET and Active Server Pages (ASP) .NET is well-designed technology from Microsoft. ASP.NET is the part that directly competes with servlets and JSP. The advantages of JSP are twofold. First, JSP is portable to multiple operating systems and Web servers; you aren't locked into deploying on Windows and IIS. Although the core .NET platform runs on a few non-Windows platforms, the ASP part does not. You cannot expect to deploy serious ASP.NET applications on multiple servers and operating systems. For some applications, this difference does not matter. For others, it matters greatly. Second, for some applications the choice of the underlying language matters greatly. For example, although .NET's C# language is very well designed and is similar to Java, fewer programmers are familiar with either the core C# syntax or the many auxiliary libraries. In addition, many developers still use the original version of ASP. With this version, JSP has a clear advantage for the dynamic code. With JSP, the dynamic part is written in Java, not VBScript or another ASP-specific language, so JSP is more powerful and better suited to complex applications that require reusable components. You could make the same argument when comparing JSP to the previous version of ColdFusion; with JSP you can use Java for the "real code" and are not tied to a particular server product. However, the current release of ColdFusion is within the context of a J2EE server, allowing developers to easily mix ColdFusion and servlet/JSP code. Versus PHP PHP (a recursive acronym for "PHP: Hypertext Preprocessor") is a free, open-source, HTML-embedded scripting language that is somewhat similar to both ASP and JSP. One advantage of JSP is that the dynamic part is written in Java, which already has an extensive API for networking, database access, distributed objects, and the like, whereas PHP requires learning an entirely new, less widely used language. A second advantage is that JSP is much more widely supported by tool and server vendors than is PHP. Versus Pure Servlets JSP doesn't provide any capabilities that couldn't, in principle, be accomplished with servlets. In fact, JSP documents are automatically translated into servlets behind the scenes. But it is more convenient to write (and to modify!) regular HTML than to use a zillion println statements to generate the HTML. Plus, by separating the presentation from the content, you can put different people on different tasks: your Web page design experts can build the HTML by using familiar tools and either leave places for your servlet programmers to insert the dynamic content or invoke the dynamic content indirectly by means of XML tags. Does this mean that you can just learn JSP and forget about servlets? Absolutely not! JSP developers need to know servlets for four reasons: 1. JSP pages get translated into servlets. You can't understand how JSP works without understanding servlets. 2. JSP consists of static HTML, special-purpose JSP tags, and Java code. What kind of Java code? Servlet code! You can't write that code if you don't understand servlet programming. 3. Some tasks are better accomplished by servlets than by JSP. JSP is good at generating pages that consist of large sections of fairly well structured HTML or other character data. Servlets are better for generating binary data, building pages with highly variable structure, and performing tasks (such as redirection) that involve little or no output. 4. Some tasks are better accomplished by a combination of servlets and JSP than by either servlets or JSP alone. Versus JavaScript JavaScript, which is completely distinct from the Java programming language, is normally used to dynamically generate HTML on the client, building parts of the Web page as the browser loads the document. This is a useful capability and does not normally overlap with the capabilities of JSP (which runs only on the server). JSP pages still include SCRIPT tags for JavaScript, just as normal HTML pages do. In fact, JSP can even be used to dynamically generate the JavaScript that will be sent to the client. So, JavaScript is not a competing technology; it is a complementary one. It is also possible to use JavaScript on the server, most notably on Sun ONE (formerly iPlanet), IIS, and BroadVision servers. However, Java is more powerful, flexible, reliable, and portable. Versus WebMacro or Velocity JSP is by no means perfect. Many people have pointed out features that could be improved. This is a good thing, and one of the advantages of JSP is that the specification is controlled by a community that draws from many different companies. So, the technology can incorporate improvements in successive releases. However, some groups have developed alternative Java-based technologies to try to address these deficiencies. This, in our judgment, is a mistake. Using a third-party tool like Apache Struts that augments JSP and servlet technology is a good idea when that tool adds sufficient benefit to compensate for the additional complexity. But using a nonstandard tool that tries to replace JSP is a bad idea. When choosing a technology, you need to weigh many factors: standardization, portability, integration, industry support, and technical features. The arguments for JSP alternatives have focused almost exclusively on the technical features part. But portability, standardization, and integration are also very important. For example, the servlet and JSP specifications define a standard directory structure for Web applications and provide standard files (.war files) for deploying Web applications. All JSP-compatible servers must support these standards. Filters can be set up to apply to any number of servlets or JSP pages, but not to nonstandard resources. The same goes for Web application security settings. Besides, the tremendous industry support for JSP and servlet technology results in improvements that mitigate many of the criticisms of JSP. For example, the JSP Standard Tag Library and the JSP 2.0 expression language address two of the most well-founded criticisms: the lack of good iteration constructs and the difficulty of accessing dynamic results without using either explicit Java code or verbose jsp:useBean elements. Misconceptions About JSP Forgetting JSP Is Server-Side Technology Here are some typical questions Marty has received (most of them repeatedly). ? Our server is running JDK 1.4. So, how do I put a Swing component in a JSP page? ? How do I put an image into a JSP page? I do not know the proper Java I/O commands to read image files. ? Since Tomcat does not support JavaScript, how do I make images that are highlighted when the user moves the mouse over them? ? Our clients use older browsers that do not understand JSP. What should we do? ? When our clients use "View Source" in a browser, how can I prevent them from seeing the JSP tags? All of these questions are based upon the assumption that browsers know something about the server-side process. But they do not. Thus: ? For putting applets with Swing components into Web pages, what matters is the browser's Java version—the server's version is irrelevant. If the browser supports the Java 2 platform, you use the normal APPLET (or Java plug-in) tag and would do so even if you were using non-Java technology on the server. ? You do not need Java I/O to read image files; you just put the image in the directory for Web resources (i.e., two levels up from WEB-INF/classes) and output a normal IMG tag. ? You create images that change under the mouse by using client-side JavaScript, referenced with the SCRIPT tag; this does not change just because the server is using JSP. ? Browsers do not "support" JSP at all—they merely see the output of the JSP page. So, make sure your JSP outputs HTML compatible with the browser, just as you would do with static HTML pages. ? And, of course you need not do anything to prevent clients from seeing JSP tags; those tags are processed on the server and are not part of the output that is sent to the client. Confusing Translation Time with Request Time A JSP page is converted into a servlet. The servlet is compiled, loaded into the server's memory, initialized, and executed. But which step happens when? To answer that question, remember two points: ? The JSP page is translated into a servlet and compiled only the first time it is accessed after having been modified. ? Loading into memory, initialization, and execution follow the normal rules for servlets. Table 1 gives some common scenarios and tells whether or not each step occurs in that scenario. The most frequently misunderstood entries are highlighted. When referring to the table, note that servlets resulting from JSP pages use the _jspService method (called for both GET and POST requests), not doGet or doPost. Also, for initialization, they use the jspInit method, not the init method. Table 1. JSP Operations in Various Scenarios JSP page translated into servlet Servlet compiled Servlet loaded into server's memory jspInit called _jspService called Page first written Request 1 Yes Yes Yes Yes Yes Request 2 No No No No Yes Server restarted Request 3 No No Yes Yes Yes Request 4 No No No No Yes Page modified Request 5 Yes Yes Yes Yes Yes Request 6 No No No No Yes JSP技術(shù)概述 一． JSP的好處 JSP頁面最終會轉(zhuǎn)換成servlet。因而，從根本上，JSP頁面能夠執(zhí)行的任何任務(wù)都可以用servlets來完成。然而，這種底層的等同性并不意味著servlets和JSP頁面對于所有的情況都等同適用。問題不在于技術(shù)的能力，而是二者在便利性、生產(chǎn)率和可維護性上的不同。畢竟，在特定平臺上能夠用Java編程語言完成的事情，同樣可以用匯編語言來完成，但是選擇哪種語言依舊十分重要。 和單獨使用servlets相比，JSP提供下述好處 l JSP中HTML的編寫與維護更為簡單。JSP中可以使用常規(guī)的HTML：沒有額外的反斜杠，沒有額外的雙引號，也沒有暗含的Java語法。 l 能夠使用標準的網(wǎng)站開發(fā)工具。即使對那些對JSP一無所知的HTML工具，我們也可以使用，因為它們會忽略JSP標簽（JSP tags）。 l 可以對開發(fā)團隊進行劃分。Java程序員可以致力于動態(tài)代碼。Web開發(fā)人員可以將經(jīng)理集中在表示層（presentation layer）上。對于大型的項目，這種劃分極為重要。依據(jù)開發(fā)團隊的大小，及項目的復(fù)雜程度，可以對靜態(tài)HTML和動態(tài)內(nèi)容進行弱分離（weaker separation）和強分離（stronger separation）。 在此，這個討論并不是讓您停止使用servlets，只使用JSP。幾乎所有的項目都會同時用到這兩種技術(shù)。針對項目中的某些請求，您可能會在MVC構(gòu)架下組合使用這兩項技術(shù)。我們總是希望用適當?shù)墓ぞ咄瓿上鄬?yīng)的工作，僅僅是servlet并不能填滿您的工具箱。 二． JSP相對于競爭技術(shù)的優(yōu)勢 許多年前，Marty受到邀請,參加一個有關(guān)軟件技術(shù)的小型(20個人)研討會.做在Marty旁邊的人是James Gosling--- Java編程語言的發(fā)明者。隔幾個位置,是來自華盛頓一家大型軟件公司的高級經(jīng)理。在討論過程中,研討會的主席提出了Jini的議題,這在當時是一項新的Java技術(shù).主席向該經(jīng)理詢問他的想法.他繼續(xù)說,他們會持續(xù)關(guān)注這項技術(shù),如果這項技術(shù)變得流行起來,他們會遵循公司的“接受并擴充(embrace and extend)”的策略.此時, Gosling隨意地插話說“你的意思其實就是不接受且不擴充(disgrace and distend)?！? 在此, Gosling的抱怨顯示出，他感到這個公司會從其他公司那里拿走技術(shù),用于他們自己的目的.但你猜這次怎么樣?這次鞋子穿在了另一只腳上。Java社團沒有發(fā)明這一思想----將頁面設(shè)計成由靜態(tài)HTML和用特殊標簽標記的動態(tài)代碼混合組成.。ColdFusion多年前就已經(jīng)這樣做了。甚至ASP(來自于前述經(jīng)理所在公司的一項產(chǎn)品)都在JSP出現(xiàn)之前推廣了這種方式。實際上,JSP不只采用了這種通用概念,它甚至使用許多和ASP相同的特殊標簽。 因此,問題變成:為什么使用JSP,而不使用其他技術(shù)呢?我們的第一反應(yīng)是我們不是在爭論所有的人應(yīng)該做什么。其他這些技術(shù)中,有一些也很不錯,在某些情況下也的確是合情合理的選擇.然而,在其他情形中,JSP明顯要更好一些。下面給出幾個理由。 與.NET和Active Server Pages (ASP)相比 .NET是Microsoft精心設(shè)計的一項技術(shù)。ASP.NET是與servlets和JSP直接競爭的技術(shù)。JSP的優(yōu)勢體現(xiàn)在兩個方面。 首先,JSP可以移植到多種操作系統(tǒng)和Web服務(wù)器,您不必僅僅局限于部署在Windows 和IIS上盡管核心.NET平臺可以在好幾種非Windows平臺上運行，但ASP這一部分不可以。您不能期望可以將重要的ASP.NET應(yīng)用部署到多種服務(wù)器和操作系統(tǒng)。對于某些應(yīng)用，這種差異沒有什么影響。但有些應(yīng)用，這種差異卻非常重要。 其次，對于某些應(yīng)用，底層語言的選擇至關(guān)重要。例如，盡管.NET的C#語言設(shè)計優(yōu)良，且和Java類似，但熟悉核心C#語法和眾多工具庫的程序員很少。此外,許多開發(fā)者依舊使用最初版本的ASP。相對于這個版本,JSP在動態(tài)代碼方面擁有明顯的優(yōu)勢。使用JSP,動態(tài)部分是用Java編寫的,而非VBScript過其他ASP專有的語言,因此JSP更為強勁,更適合于要求組件重用的復(fù)雜應(yīng)用。 當將JSP與之前版本的ColdFusion對比時，您可能會得到相同的結(jié)論。應(yīng)用JSP，您可以使用Java編寫“真正的代碼”，不必依賴于特定的服務(wù)器產(chǎn)品。然而，當前版本的ColdFusion滿足J2EE服務(wù)器的環(huán)境，允許開發(fā)者容易的混合使用ColdFusion和Servlet/JSP代碼。 與PHP相比 PHP（“PHP：Hypertext Preprocessor”的遞歸字母縮寫詞）是免費的、開放源代碼的、HTML嵌入其中的腳本語言，與ASP和JSP都有某種程度的類似。JSP的一項優(yōu)勢是動態(tài)部分用Java編寫，而Java已經(jīng)在聯(lián)網(wǎng)、數(shù)據(jù)庫訪問、分布式對象等方面擁有廣泛的API，而PHP需要學(xué)習(xí)全新的、應(yīng)用相對廣泛的語言。JSP的第二項優(yōu)勢是，和PHP相比，JSP擁有極為廣泛的工具和服務(wù)器提供商的支持。 與純Servlet相比 原則上，JSP并沒有提供Servlet不能完成的功能。實際上，JSP文檔在后臺被自動轉(zhuǎn)換成Servlet。但是編寫（和修改）常規(guī)的HTML，要比無數(shù)println語句生成HTML要方便得多。另外，通過將表示與內(nèi)容分離，可以為不同的人分配不同的任務(wù)：網(wǎng)頁設(shè)計人員使用熟悉的工具構(gòu)建HTML，要么為Servlet程序員留出空間插入動態(tài)內(nèi)容，要么通過XML標簽間接調(diào)用動態(tài)內(nèi)容。 這是否表示您只可以學(xué)習(xí)JSP，將Servlet丟到一邊呢？當然不是！由于以下4種原因，JSP開發(fā)人員需要了解Servlet： 1. JSP頁面會轉(zhuǎn)換成Servlet。不了解Servlet就無法知道JSP如何工作。 2. JSP由靜態(tài)HTML、專用的JSP標簽和Java代碼組成。哪種類型的Java代碼呢？當然是Servlet代碼！如果不了解Servlet編程，那么就無法編寫這種代碼。 3. 一些任務(wù)用Servlet完成比用JSP來完成要好。JSP擅長生成由大量組織有序的結(jié)構(gòu)化HTML或其他字符數(shù)據(jù)組成的頁面。Servlet擅長生成二進制數(shù)據(jù)，構(gòu)建結(jié)構(gòu)多樣的頁面，以及執(zhí)行輸出很少或者沒有輸出的任務(wù)（比如重定向）。 4. 有些任務(wù)更適合于組合使用Servlet和JSP來完成，而非單獨使用Servlet或JSP。 與JavaScript相比 JavaScript和Java編程語言完全是兩碼事，前者一般用于在客戶端動態(tài)生成HTML，在瀏覽器載入文檔時構(gòu)建網(wǎng)頁的部分內(nèi)容。這是一項有用的功能，一般與JSP的功能（只在服務(wù)器端運行）并不發(fā)生重疊。和常規(guī)HTML頁面一樣，JSP頁面依舊可以包括用于JavaScript的SCRIPT標簽。實際上，JSP甚至能夠用來動態(tài)生成發(fā)送到客戶端的JavaScript。因此，JavaScript不是一項競爭技術(shù)，它是一項補充技術(shù)。 JavaScript也可以用在服務(wù)器端，最因人注意的是SUN ONE（以前的iPlanet）、IIS和BroadVision服務(wù)器。然而，Java更為強大靈活、可靠且可移植。 與WebMacro和Velocity相比 JSP決非完美。許多人都曾指出過JSP中能夠改進的功能。這是一件好事，JSP的優(yōu)勢之一是該規(guī)范由許多不同公司組成的社團控制。因此，在后續(xù)版本中，這項技術(shù)能夠得到協(xié)調(diào)的改進。 但是，一些組織已經(jīng)開發(fā)出了基于Java的替代技術(shù)，試圖彌補這些不足。據(jù)我們的判斷，這樣做是錯誤的。使用擴充JSP和Servlet技術(shù)的第三方工具，如Apache Structs，是一種很好的思路，只要該工具帶來的好處能夠補償工具帶來的額外復(fù)雜性。但是，試圖使用非標準的工具代替JSP則不理想。在選擇一項技術(shù)時，需要權(quán)衡許多方面的因素：標準化、可移植性、集成性、行業(yè)支持和技術(shù)特性。對于JSP替代技術(shù)的爭論幾乎只是集中在技術(shù)特性上，而可移植性、標準化和集成性也十分重要。例如，Servlet和JSP規(guī)范為Web應(yīng)用定義了一個標準的目錄結(jié)構(gòu)，并提供用于部署Web應(yīng)用的標準文件（.war文件）。所有JSP兼容的服務(wù)器必須支持這些標準。我們可以建立過濾器作用到任意樹木的Servlet和JSP頁面上，但不能用于非標準資源。Web應(yīng)用安全設(shè)置也同樣如此。 此外，業(yè)界對JSP和Servlet技術(shù)的巨大支持使得這兩項技術(shù)都有了巨大的進步，從而減輕了對JSP的許多批評。例如，JSP標準標簽庫和JSP 2.0表達式語言解決了兩種最廣泛的批評：缺乏良好的迭代結(jié)構(gòu)；不使用顯式的Java代碼或冗長的jsp:useBean元素難以訪問動態(tài)結(jié)果。 三． 對JSP的誤解 忘記JSP技術(shù)是服務(wù)器端技術(shù) 下面是Marty收到的一些典型問題（大部分問題不止一次的出現(xiàn)）。 l 我們的服務(wù)器正在運行JDK1.4。我如何將Swing組件用到JSP頁面中呢？ l 我如何將圖像放到JSP頁面中？我不知道讀取圖像文件應(yīng)該使用哪些I/O命令。 l Tomcat不支持JavaScript，當用戶在圖像上移動鼠標時，我如何使圖像突出顯示呢？ l 我們的客戶使用不理解JSP的舊瀏覽器。我應(yīng)該怎么做？ l 當我們的客戶在瀏覽器中使用“Viewl Source”（查看源代碼）時，如何阻止他們看到JSP標簽？ l 所有這些問題都基于瀏覽器對服務(wù)器端的過程在有所了解的假定之上。但事實上瀏覽器并不了解服務(wù)器端的過程。因此： l 如果要將使用Swing組件的applet放到網(wǎng)頁中，重要的是瀏覽器的Java版本，和服務(wù)器的Java版本無關(guān)。如果瀏覽器支持Java 2平臺，您可以使用正常的APPLET（或Java插件）標簽，即使在服務(wù)器上使用了非Java技術(shù)也須如此。 l 您不需要Javal I/O來讀取圖像文件，您只需將圖像放在存儲Web資源的目錄中（即WEB-INF/classes向上兩級的目錄），并輸出一個正常的IMG標簽。 l 您應(yīng)該用SCRIPT標簽，使用客戶端JavaScript創(chuàng)建在鼠標下會更改的圖像，這不會由于服務(wù)器使用JSP而改變。 l 瀏覽器根本不“支持”JSP----它們看到的只是JSP頁面的輸出。因此，如同對待靜態(tài)HTML頁面一樣，只需確保JSP輸出的HTML與瀏覽器兼容。 l 當然，您不需要采取什么措施來阻止客戶看到JSP標簽，這些標簽在服務(wù)器上進行處理，發(fā)送給客戶的輸出中并不出現(xiàn)。 混淆轉(zhuǎn)換期間和請求期間 JSP頁面需要轉(zhuǎn)換成servlet。Servlet在編譯后，載入到服務(wù)器的內(nèi)容中，初始化并執(zhí)行。但是每一步發(fā)生在什么時候呢？要回答這個問題，要記住以下兩點： l JSP頁面僅在修改后第一次被訪問時，才會被轉(zhuǎn)換成servlet并進行編譯； l 載入到內(nèi)存中、初始化和執(zhí)行遵循servlet的一般規(guī)則。 表1列出一些常見的情形，講述在該種情況下每一步是否發(fā)生。最常被誤解的項已經(jīng)突出標示出來。在參考該表時，要注意，由JSP頁面生成的servlet使用_jspService方法（GET和POST請求都調(diào)用該函數(shù)），不是doGet或doPost方法。同樣，對于初始化，它們使用jspInit方法，而非init方法。 表1 各種情況下的JSP操作 ?將JSP 頁面轉(zhuǎn)換成servlet 編譯Servlet? 將Servlet 載入到服務(wù)器內(nèi)存中 調(diào)用jspInit? 調(diào)用_jspService 頁面初次創(chuàng)建 請求 1 有 有 有 有 有 請求 2 無 無 無 無 有 服務(wù)器重啟后 請求3 無 無 有 有 有 請求 4 無 無 無 無 有 頁面修改后 請求 5 有 有 有 有 有 請求 6 無 無 無 無 有