logo资料库

JSP相关的外文翻译.doc

第1页 / 共10页
第2页 / 共10页
第3页 / 共10页
第4页 / 共10页
第5页 / 共10页
第6页 / 共10页
第7页 / 共10页
第8页 / 共10页
资料共10页,剩余部分请下载后查看
外文原文 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. 10.4 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 技术概述 一、JSP 的好处 JSP 页面最终会转换成 servler。因而,从根本上,JSP 页面能够执行的任何任务都可以用 servler 来完 成。然而,这种底层的等同性并不意味着 servler 和 JSP 页面对于所有的情况都等同适用。问题不在于 技术的能力,而是二者在便利性、生产率和可维护性上的不同。毕竟,在特定平台上能够用 Java 编程 语言完成的事情,同样可以用汇编语言来完成,但是选择哪种语言依旧十分重要。 和单独使用 servler 相比,JSP 提供下述好处:  JSP 中 HTML 的编写与维护更为简单。JSP 中可以使用常规的 HTML:没有额外的反斜杠,没有额 外的双引号,也没有暗含的 Java 语法。  能够使用标准的网站开发工具。即使对那些对 JSP 一无所知的 HTML 工具,我们也可以使用,因 为它们会忽略 JSP 标签(JSP tags)。  可以对开发团队进行划分。Java 程序员可以致力于动态代码。Web 开发人员可以将经理集中在表示 层(presentation layer)上。对于大型的项目,这种划分极为重要。依据开发团队的大小,及项目的复 杂程度,可以对静态 HTML 和动态内容进行弱分离(weaker separation)和强分离(stronger separation)。
在此,这个讨论并不是让您停止使用 servlets,只使用 JSP。几乎所有的项目都会同时用到这两种技术。 针对项目中的某些请求,您可能会在 MVC 构架下组合使用这两项技术。我们总是希望用适当的工具 完成相对应的工作,仅仅是 servlet 并不能填满您的工具箱。 二、JSP 相对于竞争技术的优势 许多年前,Marty 受到邀请,参加一个有关软件技术的小型(20 个人)研讨会.做在 Marty 旁边的人是 James Gosling--- Java 编程语言的发明者。隔几个位置,是来自华盛顿一家大型软件公司的高级经理。在讨论 过程中,研讨会的主席提出了 Jini 的议题,这在当时是一项新的 Java 技术.主席向该经理询问他的想法. 他继续说,他们会持续关注这项技术,如果这项技术变得流行起来,他们会遵循公司的“接受并扩充 (embrace and extend)”的策略.此时, Gosling 随意地插话说“你的意思其实就是不接受且不扩充(disgrace and distend)。” 在此, Gosling 的抱怨显示出,他感到这个公司会从其他公司那里拿走技术,用于他们自己的目的.但你 猜这次怎么样?这次鞋子穿在了另一只脚上。Java 社团没有发明这一思想----将页面设计成由静态 HTML 和用特殊标签标记的动态代码混合组成.。ColdFusion 多年前就已经这样做了。甚至 ASP(来自 于前述经理所在公司的一项产品)都在 JSP 出现之前推广了这种方式。实际上,JSP 不只采用了这种通用 概念,它甚至使用许多和 ASP 相同的特殊标签。 因此,问题变成:为什么使用 JSP,而不使用其他技术呢?我们的第一反应是我们不是在争论所有的人应 该做什么。其他这些技术中,有一些也很不错,在某些情况下也的确是合情合理的选择.然而,在其他情形 中,JSP 明显要更好一些。下面给出几个理由。 与.NET 和 Active Server Pages (ASP)相比 .NET 是 Microsoft 精心设计的一项技术。ASP.NET 是与 servlets 和 JSP 直接竞争的技术。JSP 的优势 体现在两个方面。 首先,JSP 可以移植到多种操作系统和 Web 服务器,您不必仅仅局限于部署在 Windows 和 IIS 上尽管核 心.NET 平台可以在好几种非 Windows 平台上运行,但 ASP 这一部分不可以。您不能期望可以将重要 的 ASP.NET 应用部署到多种服务器和操作系统。对于某些应用,这种差异没有什么影响。但有些应 用,这种差异却非常重要。 其次,对于某些应用,底层语言的选择至关重要。例如,尽管.NET 的 C#语言设计优良,且和 Java 类 似,但熟悉核心 C#语法和众多工具库的程序员很少。此外,许多开发者依旧使用最初版本的 ASP。相 对于这个版本,JSP 在动态代码方面拥有明显的优势。使用 JSP,动态部分是用 Java 编写的,而非 VBScript 过其他 ASP 专有的语言,因此 JSP 更为强劲,更适合于要求组件重用的复杂应用。
当将 JSP 与之前版本的 ColdFusion 对比时,您可能会得到相同的结论。应用 JSP,您可以使用 Java 编写“真正的代码”,不必依赖于特定的服务器产品。然而,当前版本的 ColdFusion 满足 J2EE 服务器 的环境,允许开发者容易的混合使用 ColdFusion 和 Servlet/JSP 代码。 与 PHP 相比 PHP(“PHP:Hypertext Preprocessor”的递归字母缩写词)是免费的、开放源代码的、HTML 嵌入其中 的脚本语言,与 ASP 和 JSP 都有某种程度的类似。JSP 的一项优势是动态部分用 Java 编写,而 Java 已经在联网、数据库访问、分布式对象等方面拥有广泛的 API,而 PHP 需要学习全新的、应用相对广 泛的语言。JSP 的第二项优势是,和 PHP 相比,JSP 拥有极为广泛的工具和服务器提供商的支持。 与纯 Servlet 相比 原则上,JSP 并没有提供 Servlet 不能完成的功能。实际上,JSP 文档在后台被自动转换成 Servlet。但 是编写(和修改)常规的 HTML,要比无数 println 语句生成 HTML 要方便得多。另外,通过将表示 与内容分离,可以为不同的人分配不同的任务:网页设计人员使用熟悉的工具构建 HTML,要么为 Servlet 程序员留出空间插入动态内容,要么通过 XML 标签间接调用动态内容。 这是否表示您只可以学习 JSP,将 Servlet 丢到一边呢?当然不是!由于以下 4 种原因,JSP 开发人员 需要了解 Servlet: (1)JSP 页面会转换成 Servlet。不了解 Servlet 就无法知道 JSP 如何工作。 (2)JSP 由静态 HTML、专用的 JSP 标签和 Java 代码组成。哪种类型的 Java 代码呢?当然是 Servlet 代码!如果不了解 Servlet 编程,那么就无法编写这种代码。 (3)一些任务用 Servlet 完成比用 JSP 来完成要好。JSP 擅长生成由大量组织有序的结构化 HTML 或 其他字符数据组成的页面。Servlet 擅长生成二进制数据,构建结构多样的页面,以及执行输出很少或 者没有输出的任务(比如重定向)。 (4)有些任务更适合于组合使用 Servlet 和 JSP 来完成,而非单独使用 Servlet 或 JSP。 与 JavaScript 相比 JavaScript 和 Java 编程语言完全是两码事,前者一般用于在客户端动态生成 HTML,在浏览器载入文 档时构建网页的部分内容。这是一项有用的功能,一般与 JSP 的功能(只在服务器端运行)并不发生 重叠。和常规 HTML 页面一样,JSP 页面依旧可以包括用于 JavaScript 的 SCRIPT 标签。实际上,JSP 甚至能够用来动态生成发送到客户端的 JavaScript。因此,JavaScript 不是一项竞争技术,它是一项补 充技术。 JavaScript 也可以用在服务器端,最因人注意的是 SUN ONE(以前的 iPlanet)、IIS 和 BroadVision 服
分享到:
收藏