毕业设计--外文资料翻译-JSP技术
毕业设计JSPmvc外文翻译
Struts——一种开源MVC的实现这篇文章介绍 Struts，一个使用 servlet 和 JavaServer Pages 技术的一种 Model-View-Controller 的实现。
Struts 可以帮助你控制 Web 项目中的变化并提高专业化。
即使你可能永远不会用 Struts实现一个系统，你可以获得一些想法用于你未来的 servlet 和 JSP 网页的实现中。
简介在小学校园里的小孩子们都可以在因特网上发布 HTML 网页。
然而，有一个重大的不同在一个小学生和一个专业人士开发的之间。
网页设计师（或者 HTML开发人员）必须理解颜色、用户、生产流程、网页布局、浏览器兼容性、图像创建、JavaScript 等等。
设计漂亮的需要做大量的工作，大多数 Java 开发人员更注重创建优美的对象接口，而不是用户界面。
JavaServer Pages (JSP) 技术为网页设计人员和 Java 开发人员提供了一种联系钮带。
如果你开发过大型 Web 应用程序，你就理解“变化”这个词语。
“模型-视图-控制器”(MVC) 就是用来帮助你控制变化的一种设计模式。
MVC 减弱了业务逻辑接口和数据接口之间的耦合。
Struts 是一种 MVC 实现，它将 Servlet 2.2 和 JSP 1.1 标记（属于 J2EE 规）用作实现的一部分。
你可能永远不会用 Struts 实现一个系统，但了解一下 Struts 或许使你能将其中的一些思想用于你以后的 Servlet 和 JSP 实现中。
模型-视图-控制器 (MVC)JSP标签只解决了我们问题中的一部分。
我们依然有验证、流控制、以及更新应用程序结构的问题。
这就是MVC从哪儿来以及来干嘛的。
MVC通过把问题分成三类来帮助解决一些与单模块相关的问题：?Model（模型）模块包括应用程序功能的核心。
模型封装着应用程序的各个结构。
有时它所包含的唯一功能就是结构。
它对于视图或者控制器一无所知。
计算机 JSP web 外文翻译 外文文献
计算机 JSP web 外文翻译外文文献12.1 nEffective web n design involves separating business objects。
n。
and object XXX。
Although one individual may handle both roles on a small-scale project。
it is XXX.12.2 JSP ArchitectureIn this chapter。
XXX using JavaServer Pages。
servlets。
XXX of different architectures。
each building upon the us one。
The diagram below outlines this process。
and we will explain each component in detail later in this article.Note: XXX.)When Java Server Pages were introduced by Sun。
some people XXX。
While JSP is a key component of the J2EE n and serves as the preferred request handler and response mechanism。
it is XXX.XXX JSP。
the XXX that JSP is built on top of the servlet API and uses servlet XXX interesting ns。
such as whether we should XXX in our Web-enabled systems。
and if there is a way to combine servlets and JSPs。
jsp技术网站设计外文翻译(适用于毕业论文外文翻译+中英文对照)
Combining JSP and ServletsThe technology of JSP and Servlet is the most important technology which use Java technology to exploit request of server, and it is also the standard which exploit business application .Java developers prefer to use it for a variety of reasons, one of which is already familiar with the Java language for the development of this technology are easy to learn Java to the other is "a preparation, run everywhere" to bring the concept of Web applications, To achieve a "one-prepared everywhere realized." And more importantly, if followed some of the principles of good design, it can be said of separating and content to create high-quality, reusable, easy to maintain and modify the application. For example, if the document in HTML embedded Java code too much (script), will lead the developed application is extremely complex, difficult to read, it is not easy reuse, but also for future maintenance and modification will also cause difficulties. In fact, CSDN the JSP / Servlet forum, can often see some questions, the code is very long, can logic is not very clear, a large number of HTML and Java code mixed together. This is the random development of the defects.Early dynamic pages mainly CGI (Common Gateway Interface, public Gateway Interface) technology, you can use different languages of the CGI programs, such as VB, C / C + + or Delphi, and so on. Though the technology of CGI is developed and powerful, because of difficulties in programming, and low efficiency, modify complex shortcomings,it is gradually being replaced by the trend. Of all the new technology, JSP / Servlet with more efficient and easy to program, more powerful, more secure and has a good portability, they have been many people believe that the future is the most dynamic site of the future development of technology.Similar to CGI, Servlet support request / response model. When a customer submit a request to the server, the server presented the request Servlet, Servlet responsible for handling requests and generate a response, and then gave the server, and then from the server sent to the customer. And the CGI is different, Servlet not generate a new process, but with HTTP Server at the same process. It threads through the use of technology, reduce the server costs. Servlet handling of the request process is this: When received from the client's request, calling service methods, the method of Servlet arrival of the first judgement is what type of request (GET / POST / HEAD…), then calls the appropriate treatment (DoGet / doPos t / doHead…) and generate a response.Although such a complex, in fact, simply said to Servlet is a Java class. And the general category of the difference is that this type operating in a Servlet container, which can provide session management and targeted life-cycle management. So that when you use the Servlet, you can get all the benefits of the Java platform, including the safety of the management, use JDBC access the database and cross-platform capability. Moreover, Servlet using thread, and can develop more efficient Web applications.JSP technology is a key J2EE technology, it at a higher level of abstraction of a Servlet.It allows conventional static and dynamic HTML content generated by combining an HTML page looks like, but as a Servlet to run. There are many commercial application server support JSP technology, such as BEA WebLogic, IBM WebSphere, JRun, and so on. JSP and Servlet use more than simple. If you have a JSP support for Web servers, and a JSP document, you can put it Fangdao any static HTML files can be placed, do not have to compile, do not have to pack, do not have to ClassPath settings, you can visit as ordinary Web It did visit, the server will automatically help you to do other work.JSP document looks like an ordinary static HTML document, but inside contains a number of Java code. It uses. Jsp the suffix, used to tell the server this document in need of special treatment. When we visit a JSP page, the document will first be translated into a JSP engine Java source files, is actually a Servlet, and compiler, and then, like other Servlet, from Servlet engine to handle. Servlet engine of this type loading, handling requests from customers, and the results returned to the customer, as shown below:Figure 1: Calling the process of JSP pagesAfter another visit this page to the customer, as long as the paper there have been no changes, JSP engine has been loaded directly call the Servlet. If you have already been modified, it will be once again the implementation of the above process, translate, compile and load. In fact, this is the so-called "first person to punishment." Because when the first visit to the implementation of a series of the above process, so will spend some time after such a visit would not.Java servlets offer a powerful API that provides access to all the information about the request, the session, and the application. combining JSP with servlets lets you clearly separate the application logic from the presentation of the application; in other words, it lets you use the most appropriate component type for the roles of Model, View and Controller.Servlets, Filters, and ListenersA servlet is a Java class that extends a server with functionality for processing a request and producing a response. It's implemented using the classes and interfaces defined by the Servlet API. The API consists of two packages: the javax.servlet package contains classes and interfaces that are protocol-independent, while the javax.servlet.http package provides HTTP-specific extensions and utility classes.What makes a servlet a servlet is that the class implements an interface named javax.servlet.Servlet, either directly or by extending one of the support classes. This interface defines the methods used by the web container to manage and interact with theservlet. A servlet for processing HTTP requests typically extends the javax.servlet.http.HttpServlet class. This class implements the Servlet interface and provides additional methods suitable for HTTP processing.Servlet LifecycleThe web container manages all aspects of the servlet's lifecycle. It creates an instance of the servlet class when needed, passes requests to the instance for processing, and eventually removes the instance. For an HttpServlet, the container calls the following methods at the appropriate times in the servlet lifecycle.Besides the doGet( ) and doPost( ) methods, there are methods corresponding to the other HTTP methods: doDelete( ), doHead( ), doOptions( ), doPut( ), and doTrace( ). Typically you don't implement these methods; the HttpServlet class already takes care of HEAD, OPTIONS, and TRACE requests in a way that's suitable for most servlets, and the DELETE and PUT HTTP methods are rarely used in a web application.It's important to realize that the container creates only one instance of each servlet. This means that the servlet must be thread safe -- able to handle multiple requests at the same time, each executing as a separate thread through the servlet code. Without getting lost in details, you satisfy this requirement with regards to instance variables if you modify the referenced objects only in the init( ) and destroy( ) methods, and just read them in the request processing methods.Compiling and Installing a ServletTo compile a servlet, you must first ensure that you have the JAR file containing all Servlet API classes in the CLASSPATH environment variable. The JAR file is distributed with all web containers. Tomcat includes it in a file called servlet.jar, located in the common/lib directory. On a Windows platform, you include the JAR file in the CLASSPATH.. Reading a RequestOne of the arguments passed to the doGet( ) and doPost( ) methods is an object that implements the HttpServletRequest interface. This interface defines methods that provide access to a wealth of information about the request.Generating a ResponseBesides the request object, the container passes an object that implements the HttpServletResponse interface as an argument to the doGet( ) and doPost( ) methods. This interface defines methods for getting a writer or stream for the response body. It also defines methods for setting the response status code and headers.Using Filters and ListenersThe servlet specification defines two component types beside servlets: filters and listeners. These two types were introduced in the Servlet 2.3 specification, so if you're using a container that doesn't yet support this version of the specification, I'm afraid you'reout of luck.FiltersA filter is a component that can intercept a request targeted for a servlet, JSP page, or static page, as well as the response before it's sent to the client. This makes it easy to centralize tasks that apply to all requests, such as access control, logging, and charging for the content or the services offered by the application. A filter has full access to the body and headers of the request and response, so it can also perform various transformations. One example is compressing the response body if the Accept-Language request header indicates that the client can handle a compressed response.A filter can be applied to either a specific servlet or to all requests matching a URL pattern, such as URLs starting with the same path elements or having the same extension. ListenersListeners allow your application to react to certain events. Prior to Servlet 2.3, you could handle only session attribute binding events (triggered when an object was added or removed from a session). You could do this by letting the object saved as a sessionattribute(using the HttpSession.setAttribute() method)implement the HttpSessionBindingListener interface. With the new interfaces introduced in the 2.3 version of the specification, you can create listeners for servlet context and session lifecycle events as well as session activation and passivation events (used by a container that temporarily saves session state to disk or migrates a session to another server). A newsession attribute event listener also makes it possible to deal with attribute binding events for all sessions in one place, instead of placing individual listener objects in each session.The new types of listeners follow the standard Java event model. In other words, a listener is a class that implements one or more of the listener interfaces. The interfaces define methods that correspond to events. The listener class is registered with the container when the application starts, and the container then calls the event methods at the appropriate times.Initializing Shared Resources Using a ListenerBeans like this typically need to be initialized before they can be used. For instance, they may need a reference to a database or some other external data source and may create an initial information cache in memory to provide fast access even to the first request for data. You can include code for initialization of the shared resources in the servlet and JSP pages that need them, but a more modular approach is to place all this code in one place and let the other parts of the application work on the assumption that the resources are already initialized and available. An application lifecycle listener is a perfect tool for this type of resource initialization. This type of listener implements the javax.servlet.ServletContextListener interface, with methods called by the container when the application starts and when it shuts down.Picking the Right Component Type for Each TaskThe Project Billboard application introduced is a fairly complex application. Half thepages are pure controller and business logic processing, it accesses a database to authenticate users, and most pages require access control. In real life, it would likely contain even more pages, for instance, pages for access to a shared document archive, time schedules, and a set of pages for administration. As the application evolves, it may become hard to maintain as a pure JSP application. It's easy to forget to include the access control code in new pages.This is clearly an application that can benefit from using a combination of JSP pages and the component types defined by the servlet specification for the MVC roles. Let's look at the main requirements and see how we can map them to appropriate component types:●Database access should be abstracted, to avoid knowledge of a specific dataschema or database engine in more than one part of the application: beans in therole of Model can be used to accomplish this.●The database access beans must be made available to all other parts of theapplication when it starts: an application lifecycle event listener is the perfectcomponent type for this task.●Only authenticated users must be allowed to use the application: a filter canperform access control to satisfy this requirement.●Request processing is best done with Java code: a servlet, acting as the Controller,fits the bill.●It must be easy to change the presentation: this is where JSP shines, acting as theView.Adding servlets, listeners, and filters to the mix minimizes the need for complex logic in the JSP pages. Placing all this code in Java classes instead makes it possible to use a regular Java compiler and debugger to fix potential problems.Centralized Request Processing Using a ServletWith a servlet as the common entry point for all application requests, you gain control over the page flow of the application. The servlet can decide which type of response to generate depending on the outcome of the requested action, such as returning a common error page for all requests that fail, or different responses depending on the type of client making the request. With the help from some utility classes, it can also provide services such as input validation, I18N preparations, and in general, encourage a more streamlined approach to request handling.When you use a servlet as a Controller, you must deal with the following basic requirements:●All requests for processing must be passed to the single Controller servlet.●The servlet must be able to distinguish requests for different types of processing.Here are other features you will want support for, even though they may not be requirements for all applications:● A strategy for extending the application to support new types of processingA mechanism for changing the page flow of the application without modifyingcode.Mapping Application Requests to the ServletThe first requirement for using a Controller servlet is that all requests must pass through it. This can be satisfied in many ways. If you have played around a bit with servlets previously, you're probably used to invoking a servlet with a URI that starts with /myApp/servlet. This is a convention introduced by Suns Java Web Server (JWS), the first product to support servlets before the API was standardized. Most servlet containers support this convention today, even though it's not formally defined in the servlet specification.将Servlet和JSP组合使用Servlet和JSP技术是用Java开发服务器端应用的主要技术，是开发商务应用表示端的标准。
JSP及其WEB技术毕业设计论文中英文资料对照外文翻译文献
中英文资料对照外文翻译文献JSP及其WEB技术. 1 JSP简介JSP（JavaServer Pages）是一种基于Java的脚本技术。
是由Sun Microsystems 公司倡导、许多公司参与一起建立的一种动态网页技术标准。
JSP技术有点类似ASP 技术，它是在传统的网页HTML文件(*.htm,*.html)中插入Java程序段(Scriptlet)和JSP标记(tag)，从而形成JSP文件(*.jsp)。
用JSP开发的Web应用是跨平台的，即能在Linux下运行，也能在其他操作系统上运行。
在JSP 的众多优点之中，其中之一是它能将 HTML 编码从 Web 页面的业务逻辑中有效地分离出来。
用 JSP 访问可重用的组件，如 Servlet、JavaBean 和基于 Java 的 Web 应用程序。
JSP 还支持在Web 页面中直接嵌入 Java 代码。
可用两种方法访问 JSP 文件：浏览器发送 JSP 文件请求、发送至 Servlet 的请求。
JSP技术使用Java编程语言编写类XML的tags 和scriptlets，来封装产生动态网页的处理逻辑。
网页还能通过tags和scriptlets 访问存在于服务端的资源的应用逻辑。
JSP将网页逻辑与网页设计和显示分离，支持可重用的基于组件的设计，使基于Web的应用程序的开发变得迅速和容易。
Web服务器在遇到访问JSP网页的请求时，首先执行其中的程序段，然后将执行结果连同JSP文件中的HTML代码一起返回给客户。
插入的Java程序段可以操作数据库、重新定向网页等，以实现建立动态网页所需要的功能。
JSP与Java Servlet一样，是在服务器端执行的，通常返回该客户端的就是一个HTML文本，因此客户端只要有浏览器就能浏览。
JSP页面由HTML代码和嵌入其中的Java代码所组成。
服务器在页面被客户端请求以后对这些Java代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。
网页设计毕设外文翻译--基于JSP网页自动生成工具的设计与实现
附件1：外文资料翻译译文基于JSP网页自动生成工具的设计和实现Web开发技术是Internet使用的一个重要方面，而JSP又是Web开发的最先进的技术，是当前Web开发人员的首选技术。
但是由于JSP对Web开发人员要求较高，所以许多一般的Web开发人员还不能够使用这一项先进的技术。
讨论基于模板和标签库的JSP网页自动生成工具的设计和实现，提出具体的设计思想和实现方法。
随着WWW（World Wide Web）的普及，动态网页技术也急速发展。
从原来的CGI（Common Gateway In－terface）到ASP（Active Server Page），都从某种程度上满足了网页开发人员对动态网页开发技术的需求。
但是不管是CGI还是ASP都存在一定的局限性，如CGI对服务器资源的耗费，ASP只能同Microsoft IIS 一起使用等，这些都限制了这些技术的使用范围，极大地阻碍了它们的推广。
广大的页面开发人员都热切地盼望一种统一的页面开发技术，该技术应该具有的特点：①和操作平台无关，能够在任何Web或使用程序服务器上运行；②将使用程序逻辑和页面显示分离；③提供代码重用，简化开发基于Web的交互式使用程序的过程。
JSP（Java Server Page）技术就是被设计用来满足这样的要求的。
JSP是由Sun MicroSystem公司于1999年6月推出的新的网页开发技术，它是基于Java Serv－let以及整个Java体系的Web开发技术，是Servlet2．1API的扩展。
利用这一技术，可以建立先进、安全和跨平台的动态网站。
Java是未来的主流开发技术，具有很多优势。
JSP则是Java在Internet／Intranet Web上的重要使用技术，得到了广泛的支持和承认，它可以和各种Java 技术完好地结合在一起，从而实现非常复杂的使用。
作为一种基于文本的、以显示为中心的开发技术，JSP提供了Java Servlet 的所有好处。
JSP技术中英文对照外文翻译文献
(文档含英文原文和中文翻译)中英文对照外文翻译JSP技术Java Server Pages(JSP)是一种基于web的脚本编程技术，类似于网景公司的服务器端Java脚本语言—— server-side JavaScript(SSJS)和微软的Active Server Pages(ASP)。
与SSJS和ASP相比，JSP具有更好的可扩展性，并且它不专属于任何一家厂商或某一特定的Web服务器。
尽管JSP规范是由Sun公司制定的，但任何厂商都可以在自己的系统上实现JSP。
在Sun正式发布JSP(Java Server Pages)之后，这种新的Web应用开发技术很快引起了人们的关注。
JSP为创建高度动态的Web应用提供了一个独特的开发环境。
按照Sun的说法，JSP能够适应市场上包括Apache WebServer、IIS4.0在内的85%的服务器产品。
本文将介绍JSP相关的知识，以及JavaBean的相关内容，当然都是比较粗略的介绍其中的基本内容，仅仅起到抛砖引玉的作用，如果读者需要更详细的信息，请参考相应的JSP的书籍。
1.1 概述JSP(Java Server Pages)是由Sun Microsystems公司倡导、许多公司参与一起建立的一种动态网页技术标准，其在动态网页的建设中有其强大而特别的功能。
JSP与Microsoft的ASP技术非常相似。
两者都提供在HTML代码中混合某种程序代码、由语言引擎解释执行程序代码的能力。
下面我们简单的对它进行介绍。
JSP页面最终会转换成servlet。
因而，从根本上，JSP页面能够执行的任何任务都可以用servlet来完成。
然而，这种底层的等同性并不意味着servlet和JSP 页面对于所有的情况都等同适用。
问题不在于技术的能力，而是二者在便利性、生产率和可维护性上的不同。
毕竟，在特定平台上能够用Java编程语言完成的事情，同样可以用汇编语言来完成，但是选择哪种语言依旧十分重要。
外文文献JSP中英文翻译
THE TECHNIQUE DEVELOPMENT HISTORY OF JSPBy:Kathy Sierra and Bert BatesSource:Servlet&JSPThe Java Server Pages( JSP) is a kind of according to web of the script plait distance technique，similar carries the script language of Java in the server of the Netscape company of server- side JavaScript( SSJS) and the Active Server Pages（ASP）of the Microsoft。
JSP compares the SSJS and ASP to have better can expand sex, and it is no more exclusive than any factory or some one particular server of Web. Though the norm of JSP is to be draw up by the Sun company of, any factory can carry out the JSP on own system.The After Sun release the JSP（the Java Server Pages) formally，the this kind of new Web application development technique very quickly caused the people’s concern。
JSP provided a special development environment for the Web application that establishes the high dynamic state。
计算机专业毕业设计外文翻译--JSP内置对象
附录1 外文参考文献（译文）JSP内置对象有些对象不用声明就可以在JSP页面的Java程序片和表达式部分使用，这就是JSP 的内置对象。
JSP的内置对象有：request、response、session、application、out.response和request对象是JSP内置对象中较重要的两个，这两个对象提供了对服务器和浏览器通信方法的控制。
直接讨论这两个对象前，要先对HTTP协议—Word Wide Wed底层协议做简单介绍。
Word Wide Wed是怎样运行的呢？在浏览器上键入一个正确的网址后，若一切顺利，网页就出现了。
使用浏览器从网站获取HTML页面时，实际在使用超文本传输协议。
HTTP规定了信息在Internet上的传输方法，特别是规定吧浏览器与服务器的交互方法。
从网站获取页面时，浏览器在网站上打开了一个对网络服务器的连接，并发出请求。
服务器收到请求后回应，所以HTTP协议的核心就是“请求和响应”。
一个典型的请求通常包含许多头，称作请求的HTTP头。
头提供了关于信息体的附加信息及请求的来源。
其中有些头是标准的，有些和特定的浏览器有关。
一个请求还可能包含信息体，例如，信息体可包含HTML表单的内容。
在HTML表单上单击Submit 键时，该表单使用ACTION=”POST”或ACTION=”GET”方法，输入表单的内容都被发送到服务器上。
该表单内容就由POST方法或GET方法在请求的信息体中发送。
服务器发送请求时，返回HTTP响应。
响应也有某种结构，每个响应都由状态行开始，可以包含几个头及可能的信息体，称为响应的HTTP头和响应信息体，这些头和信息体由服务器发送给客户的浏览器，信息体就是客户请求的网页的运行结果，对于JSP 页面，就是网页的静态信息。
用户可能已经熟悉状态行，状态行说明了正在使用的协议、状态代码及文本信息。
例如，若服务器请求出错，则状态行返回错误及对错误描述，比如HTTP/1.1 404 Object Not Found。
jsp网站开发毕设外文翻译
jsp网站开发毕设外文翻译西安邮电大学外文文献翻译院 (系): 计算机学院专业: 计算机科学与技术班级:学生姓名: 导师姓名: 职称:起止时间:2011年 9月23日至 2012年 6月2日原文:Java and the InternetAlthough Java is very useful for solving traditional stand-alone programming problems, it is also important because it will solve programming problems on the World Wide Web.1. Client-side programmingThe Web’s initial server-browser design provided for interactive content, but the interactivity was completely provided by the server. The server produced static pages for the client browser, which would simply interpret and display them. Basic HTML contains simple mechanisms for data gathering: text-entry boxes, check boxes, radio boxes, lists and drop-down lists, as well as a button that can only be programmed to reset t he data on the form or “submit” the data on the form back to the server. This submission passes through the Common Gateway Interface (CGI) provided on all Web servers. The text within the submission tells CGI what to do with it. The most common action is to run a programlocated on the server in a directory that’s typically called “cgi-bin.” (If you watch the address window at the topof your browser when you push a button on a Web page, you can sometimes see “cgi-bin” within all thegobbledygook there.) These programs can be written in most languages. Perl is a common choice because it is designed for text manipulation and is interpreted, so it can be installed on any server regardless of processor or operating system.Many powerful Web sites today are built strictly on CGI, and you can in fact do nearly anything with it. However, Web sites built on CGI programs can rapidly become overly complicated to maintain, and there is also the problem of response time. The response of a CGI program depends on how much data must be sent, as well as the load on both the serverand the Internet. (On top of this, starting a CGI program tends to be slow.) The initial designers of the Web did not foresee how rapidly this bandwidth would be exhausted for the kinds of applications people developed. For example, any sort of dynamic graphing is nearlyimpossible to perform with consistency because a GIF file must becreated and moved from the server to the client for each version of the graph. And you’ve no doubt had direct ex perience with something as simple as validating the data on an input form. You press the submit button on a page; the data is shipped back to the server; the server starts a CGI program that discovers an error, formats an HTML page informing you of the error, and then sends the page back to you; youmust then back up a page and try again. Not only is this slow, it’s inelegant.The solution is client-side programming. Most machines that run Web browsers are powerful engines capable of doing vast work, and with the original static HTML approach they are sitting there, just idly waiting for the server to dish up the next page. Client-side programming means that the Web browser is harnessed to do whatever work it can, and the result for the user is a much speedier and more interactive experience at your Web site.The problem with discussions of client-side programming is that they aren’t very different fromdiscussions of programming in general. The parameters are almost the same, but the platform is different: a Web browser is like a limited operating system. In the end, you must still program, and this accounts for the dizzying array of problems and solutions produced by client-side programming. The rest of this section provides an overview of the issues and approaches in client-side programming. 2.Plug-insOne of the most significant steps forward in client-side programming is the development of the plug-in. This is a way for a programmer to add new functionality to the browser by downloading a piece of code that plugs itself into the appropriate spot in the browser. It tells the browser “from now on you can perform this new activity.” (You need to download the plug-in only once.) Some fast and powerfulbehavior is added to browsers via plug-ins, but writing a plug-in is not a trivial task, and isn’t somethingyou’d want to do as part of the process of building a particular site. The value of the plug-in forclient-side programming is that it allows an expert programmer to develop a new language and add that language to a browser without the permission of the browser manufacturer. Thus, plug-ins provide a “back door” that allows the creation of new client-side programming languages (although not alllanguages are implemented as plug-ins).3.Scripting languagesPlug-ins resulted in an explosion of scripting languages. With a scripting language you embed the source code for your client-side program directly into the HTML page, and the plug-in that interpretsthat language is automatically activated while the HTML page is being displayed. Scripting languages tend to be reasonably easy to understand and, because they are simply text that is part of an HTML page, they load very quickly as part of the single server hit required to procure that page. The trade-off is that your code is exposed for everyone to see (and steal). Generally, however, you aren’t doing amazingly sophisticated things with scripting languages so this is not too much of a hardship. This points out that the scripting languages used inside Web browsers are really intended to solve specific types of problems, primarily the creation of richer and more interactive graphical userinterfaces (GUIs). However, a scripting language might solve 80 percent of the problems encountered in client-side programming. Your problems might very well fit completely within that 80 percent, and sincescripting languages can allow easier and faster development, you should probably consider a scripting language before looking at a more involved solution such as Java or ActiveX programming. The most commonly discussed browser scripting languages are JavaScript (which has nothing to do with Java; it’s named that way just to grab some of Java’s marketing momentum), VBScript (whichlooks like Visual Basic), and Tcl/Tk, which comes from the popular cross-platform GUI-building language. There are others out there, and no doubt more in development.JavaScript is probably the most commonly supported. It comes builtinto both Netscape Navigatorand the Microsoft Internet Explorer (IE). In addition, there are probably more JavaScript books available than there are for the other browser languages, and some tools automatically create pages using JavaScript. However, if you’re already fluent in Visual Basic or Tcl/Tk, you’ll be mor e productive using those scripting languages rather than learning a new one. (You’ll have your hands full dealing with the Web issues already.)4.JavaIf a scripting language can solve 80 percent of the client-side programming problems, what about the other 20 percent—the “really hardstuff?” The most popular solution today is Java. Not only is it a powerful programming language built to be secure, cross-platform, and international, but Java is being continually extended to provide language features and libraries that elegantly handle problems that are difficult in traditional programming languages, such as multithreading, database access, network programming, and distributed computing. Java allows client-side programming via the applet. An applet is a mini-program that will run only under a Web browser. The applet is downloaded automatically as part of a Web page (just as, for example, a graphic is automatically downloaded).it provides you with a When the applet is activated it executes a program. This is part of its beauty—way to automatically distribute the client software from the server at the time the user needs the client software, and no sooner. The user gets the latest version of the client software without fail and without difficult reinstallation. Because of the way Java is designed, the programmer needs to create only a single program, and that program automatically works with all computers that have browsers with built-in Java interpreters. (This safely includes the vast majority of machines.) Since Java is a full-fledged programming language, you can do as much work as possible on the client before and after making requests of the server. For example, you won’t need to send a request form across the Internet todiscover that you’ve gotten a d ate or some other parameter wrong, and your client computer can quickly do the work of plotting data instead of waiting for the server to make a plot and ship a graphic image back to you. Not only do you get the immediate win of speed and responsiveness, but the general network traffic and load on servers can be reduced, preventing the entire Internet from slowing down. One advantage a Java applet has over a scripted program is that it’s in compiled form, so the sourcecode isn’t available to the client. O n the other hand, a Javaapplet can be decompiled without too much trouble, but hiding your code is often not an important issue. Two other factors can be important. As you will see later in this book, a compiled Java applet can comprise many modules and t ake multiple server “hits” (accesses) to download. (In Java 1.1 and higher this is minimized by Java archives, called JAR files, that allow all the required modules to be packaged together and compressed for a single download.) A scripted program will just be integrated into the Web page as part of its text (and will generally be smaller and reduce server hits). This could be important to the responsiveness of your Web site. Another factor is the all-important learning curve. Regardless of what you’ve heard, Java is not a trivial language to learn. If you’re a Visual Basic programmer, moving to VBScript will be your fastest solution, and since it will probably solve most typical client/server problems you might be hard pressed to justify learning Java. If yo u’re experienced with a scripting language you willcertainly benefit from looking at JavaScript or VBScript before committing to Java, since they might fit your needs handily and you’ll bemore productive sooner.to run its applets withi5.ActiveXTo so me degree, the competitor to Java is Microsoft’s ActiveX, although it takes a completely different approach. ActiveX wasoriginally a Windows-only solution, although it is now being developed via an independent consortium to become cross-platform. Effectively, ActiveX says “if yourprogram connects to its environment just so, it can be dropped into a Web page and run under a browser that supports ActiveX.” (IE directly supports ActiveX and Netscape does so using a plug-in.) Thus, ActiveX does not constrain you to a particular language. If, for example, you’re already an experienced Windows programmer using a language such as C++, Visual Basic, or Borland’s Delphi, you can create ActiveX components with almost no changes to your programming knowledge. ActiveX also provides a path for the use of legacy code in your Web pages.6.Internet vs. intranetThe Web is the most general solution to the client/server problem,so it makes sense that you can use the same technology to solve a subset of the problem, in particular the classic client/server problem within a company. With traditional client/server approaches you have the problemof multiple types of client computers, as well as the difficulty of installing new client software, both of which are handily solved with Web browsers and client-side programming. When Web technology is used for an information network that is restricted to a particular company, it is referred to as an intranet. Intranets provide much greater security than the Internet, since you can physically control access to the servers within your company. In terms of training, it seems that once people understand the general concept of a browser it’s much easier for them to deal with differences in the way pages and applets look, so thelearning curve for new kinds of systems seems to be reduced.The security problem brings us to one of the divisions that seems to be automatically forming in the world of client-side programming. If your program is running on the Internet, you don’t know what platform it will be working under, and you want to be extra careful that you don’t disseminate buggy code. You need something cross-platform and secure, like a scripting language or Java. If you’re running on an intranet, you might have a different set of constraints. It’s not uncommon that your machines could all be Intel/Windows platforms. On an intranet, you’re responsible for the quality of your own code and can repair bugs when they’re discovered. In addition, you might already have abody of legacy code that you’ve been using in a more traditional client/server approach, whereby you must physically install clientprograms every time you do an upgrade. The time wasted in installing upgrades is the most compelling reason to move to browsers, because upgrades are invisible and automatic. If you are involved in such an intranet, the most sensible approach to take is the shortest path that allows you to use your existing code base, rather than trying to recode your programs in a new language.When faced with this bewildering array of solutions to the client-side programming problem, the bestplan of attack is a cost-benefit analysis. Consider the constraints of your problem and what would be the shortest path to your solution. Since client-side programming is still programming, it’s always a good idea to take the fastest development approach for your particular situation. This is an aggressive stance to prepare for inevitable encounters with the problems of program development.翻译:Java和因特网Java除了可解决传统的程序设计问题以外，还能解决World Wide Web(万维网)上的编程问题。
JSP技术外文翻译
JSP Technology（外文原文）JSP (JavaServer Pages) is a kind of based on Java script technology. In many of the advantages of JSP, one of which is it can the HTML code from Web pages in the business logic of the effectively separated. With JSP visit reusable components, such as Servlet, JavaBean and based on Java Web applications. JSP also support in Web page direct embedded Java code. The two methods can visit JSP files: browser to send files request, sent to the JSP Servlet request.JavaServer Pages technology is an extension of the Java Servlet technology. Servlets are platform-independent, server-side modules that fit seamlessly into a Web server framework and can be used to extend the capabilities of a Web server with minimal overhead, maintenance, and support. Unlike other scripting languages, servlets involve no platform-specific consideration or modifications; they are application components that are downloaded, on demand, to the part of the system that needs them. Together, JSP technology and servlets provide an attractive alternative to other types of dynamic Web scripting/programming by offering: platform independence; enhanced performance; separation of logic from display; ease of administration; extensibility into the enterprise; and, most importantly, ease of use.The Unified Expression Language (EL)The simple EL included in JSP technology offers many advantages to the page author. Using simple expressions, page authors can easily access external data objects from their pages. The JSP technology container evaluates and resolves these expressions as it encounters them. It then immediately returns a response because the JSP request-processing model has only one phase, the render phase. However, because therequest-processing model does not support a postback, all JSP expressions are read-only.Unlike JSP technology, JavaServer Faces technology supports a multiphase life cycle. When a user enters values into the JavaServer Faces UI components and submits the page, those values are converted, validated, and propagated to server-side data objects, after which component events are processed. In order to perform all these tasks in an orderly fashion, the JavaServer Faces life cycle is split into separate phases. Therefore, JavaServer Faces technology evaluates expressions at different phases of the life cycle rather than immediately, as JSP technology would do.JSP technology -- friend or foe?Presentation technology was designed to transform plain ol' raw Web content into content wrapped in an attractive presentation layer. JavaServer Pages (JSP) technology, Sun's presentation model and part of the J2EE platform, has received significant attention. There are both advantages and disadvantages to using JSP technology, and Web developers should be aware of the good and the bad -- and know that they don't have to be limited to this single technology. In fact, these days a number of presentation technologies are available. This article begins by defining the problems presentation technologies were designed to solve. It then examines the specific strengths and weaknesses of the JSP model. Finally, it introduces some viable alternatives to Sun's presentation technology.A bit of historyBefore diving into an explanation of presentation technology, it's helpful to fill in some details on the situation that led to the birth of the technology. Just 10 short years ago, the term thin client was a novelty. We still lived in a world of desktop applications, powered by wimpy 286 microprocessors with 14-inch monitors that we squinted at. Boy, have times changed! Now my desktop does nothing but powera Web browser, while servers from Sun, IBM, HP, Compaq, and the rest churn out computations, business logic, and content. And that little monitor? Replaced by flat-screen, plasma, whopping 21- and 25-inch beauties. Why? So we can see the intricate and complex HTML displays that serve as a front-end to these powerful applications. No longer does a clunky interface suffice; now we expect flashy graphics, moving images, color-coordinated presentations that would look good in any room in the house, and speedy rendering to boot.The premiseToday, a decade beyond those fledgling Windows applications, we are still dealing with this huge shift in the presentation paradigm. The woeful Visual Basic and C programmers who remain now find themselves working either on back-end systems or Windows-only applications, or they have added a Web-capable language such as the Java language to their toolbox. An application that doesn't support at least three of four ML-isms -- such as HTML, XML, and WML -- is considered shabby, if not an outright failure. And, of course, that means we all care very deeply about the ability to easily develop a Web presentation it turns out, using the new Internet, and all the languages we have at our disposal -- Java, C, Perl, Pascal, and Ada, among others -- hasn't been as easy as we might have hoped. A number of issues creep up when it comes to taking the programming languages everyone used for back-end systems and leveraging them to generate markup language suitable for a client. With the arrival of more options on the browser (DHTML and JavaScript coding, for example), the increase in graphic artist talent in the Web domain, and tools that could create complex interfaces using standard HTML, the demand for fancy user interfaces has grown faster than our ability to develop these front ends to our applications. And this has given rise to presentation technology was designed to perform a single task: convert content, namely data without display details, intopresentation -- meaning the various user interfaces you see on your phone, PalmPilot, or Web browser. What are the problems that these presentation technologies claimed to solve? Let's take a look.Segregation vs. integrationThe primary purpose of presentation technology is to allow a separation between content and presentation. In other words, business logic units (presumably in some programming language like C or Java) don't have to generate data in a presentation-specific manner. Data, or content, is returned raw, without formatting. The presentation technology then applies formatting, or presentation, to this content. The result is an amalgam of data surrounded by and intertwined with graphics, formatting, colors, and at the examples in Listing 1 and Listing 2 to see at a glance the difference between raw content and content combined with presentation 1 shows raw content, with nothing but data, that could be used in a variety of ways.class=displaycodeRussell CroweTom HanksMeg RyanMary Stuart MastersonAlec BaldwinAshley JuddKeanu ReevesListing 2, which is much more complex than the one above, shows the same data wrapped in presentation technology and ready for display in an HTML-capable browser.class=displaycode<HTML><HEAD><TITLE>Search Results: Actors</TITLE></HEAD><BODY><H2 ALIGN="center">Search Results: Actors</H2><CENTER><HR width="85%"><TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1" BGCOLOR="#FFFFCC"><TR BGCOLOR="#FFCCCC"><TH width="50%" ALIGN="center">Last Name</TH><TH width="50%" ALIGN="center">First Name</TH></TR><TR><TD width="50%">Baldwin</TD><TD width="50%">Alec</TD></TR><TR><TD width="50%">Crowe</TD><TD width="50%">Russell</TD></TR><TR><TD width="50%">Hanks</TD><TD width="50%">Tom</TD></TR><TR><TD width="50%">Judd</TD><TD width="50%">Ashley</TD></TR><TR><TD width="50%">Masterson</TD><TD width="50%">Mary Stuart</TD></TR><TR><TD width="50%">Reeves</TD><TD width="50%">Keanu</TD></TR><TR><TD width="50%">Ryan</TD><TD width="50%">Meg</TD></TR></TABLE></CENTER>While the content in Listing 1 is clear and easy for the uninitiated layperson to both use and understand, the content in Listing 2 is very specific to the task of display in a browser. It is tricky to extract data from it or manipulate it for any other fundamental difference, the process of segregating content from presentation instead of integrating the two (at least until the user needs the information), is the basic premise of any presentation technology, including the JSP technology. Further, any presentation technology that does not accomplish this basic goal does not truly accomplish the goal it was created to achieve.Work vs. reworkBesides the separation of content and presentation, another measure of a presentation technology's usefulness is the amount of rework that it eliminates. The divergence of presentation and content enforces a divergence in the roles of those developing the content. A programmer can focus on the raw content presented in the examples above, and a graphic artist or webmaster can attend to the presentation. A slight overlap ofroles remains, however, in the process of taking the presentation -- or markup -- designed by the artist and applying it to the content the programmer's code the simplest case, the artist supplies the markup, and the developer provides code and also plugs the markup into the presentation technology. The application is "started up," and the content magically becomes a user interface. Of course, as we all know, development rarely ends there. Next come revisions and changes to the interface and new business rules that must be coded. This is where the true test of the presentation technology's flexibility comes into play. While it is usually simple to update the raw content being fed into the presentation layer, rarely can the graphic artists easily edit their original work. Changes to the presentation layer are common (we've all been victim to marketing departments changing this or that). So now a problem arises: what do the designers change to tweak their work? The original markup language page they gave to the developer? Probably not, as that page has most likely had custom tags or code inserted (JSP pages, template engines), converted to a Java servlet, or changed into something totally the designer must rework the original page and resubmit this page to the developer. Then the developer has to reconvert this page to the specific format needed for use in the presentation technology. Alternatively, the designer has to learn a scripting language or at least know that which areas of the page's source code from the developer are off limits. Of course, this is an error-prone, dangerous way to operate. Once you've determined that a presentation technology allows a clean split between content and presentation, you should try to ensure that a minimum amount of rework is necessary in order to make presentation changes.The promise of JSP technologyNow, on to the specifics of JSP coding. The promise of JSP technologyis to supply the designer and developer the only presentation technology they will ever need. JSP technology is part of the J2EE platform, which is the strongest show of support Sun can give one of its Java products. To give you an idea of how prevalent this solution is, try running a search on 'JSP' at ; you'll find more books devoted to JSP technology than about almost any other single Java API. Before I dive into the specific problems that JSP technology presents, you need a clear understanding of what it claims to do.Content vs. presentationAbove all, JSP technology is about separating content from presentation, foremost in Sun's published set of goals for JSP pages. In fact, JSP design stemmed directly from the complaints of developers who were tired of typing ("<HTML><HEAD><TITLE>" + () + "</TITLE></HEAD>"); into their servlet code. This mixing of hard-coded content with runtime variables presented a horrible burden on servlet developers. It also made making even minor changes to the presentation layer difficult for the technology addresses this situation by allowing normal HTML pages (and later, WML or other markup language pages) to be compiled at runtime into a Java servlet, essentially mimicking the () paradigm, without requiring the developer to write this code. And it allows you to insert variables into the page that are not interpreted until a JSP page the HTML snippet shown in could look like the example in Listing 3.class=displaycode<%@ page import="" %><%@ page import="" %><%PageInfo pageInfo = (PageInfo)("PAGE_DATA")%><HTML><HEAD><TITLE><%=()%></TITLE></HEAD><BODY><!-- Other HTML content --></BODY></HTML>Judging by these initial principles, then, JSP technology (at least in its stated design) would satisfy the first tenet of a presentation technology, as outlined above: that content be separated from presentation.Code vs. markupSecond on the JSP technology's list of features is something that might raise a bit of concern. JSP coding lets you insert Java code directly into a page of markup. To understand why this decision was made, recall that when the JSP specification was being developed, Sun's competition from Microsoft was at an all-time high, primarily due to the success of Microsoft Active Server Pages (ASP). The similarity of the name JavaServer Pages to Active Server Pages was not merely coincidental. And the ability to mimic many of ASP's features was also intentional. So JSP authors were given the option to add Java code into their an example of Java code being added to markup, the JSP snippet in Listing 4 dynamically adds rows as needed to show each item in the Vector of actors.class=displaycode<%@ page import="" %><%@ page import="" %><%@ page import="" %><%@ page import="" %><%@ page import="" %><%PageInfo pageInfo = (PageInfo)("PAGE_DATA")Vector actors = ()%><HTML><HEAD><TITLE><%=()%></TITLE></HEAD><BODY><H2 ALIGN="center">Search Results: Actors</H2><CENTER><HR width="85%"><TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1" BGCOLOR="#FFFFCC"><%for (Iterator i = (); ()) {Actor actor = (Actor)();%><TR BGCOLOR="#FFCCCC"><TH width="50%" ALIGN="center"><%=()%></TH><TH width="50%" ALIGN="center"><%=()%></TH></TR><%}%></TABLE></CENTER></BODY></HTML>Remember that so far I am simply describing the initial design goals of JSP technology; I'll defer my own judgment about the goals until a later section about the problems of JSP technology. You might be a little suspicious already, however, since embedding code into a JSP page would seem to cause problems with the first goal of JSP technology, separating content from presentation. But really (ahem), I'm not editorializing yet.Designer vs. developerA final (and admirable) goal of JSP technology worth mentioning is that it seeks to establish clearly defined roles in the application development process. By ostensibly breaking content from presentation, JSP technology creates a clearer distinction between the designer and developer. The designer creates markup, using only standard HTML, WML, or whatever language is appropriate, and the developer writes code. Of course, many designers today have learned JavaScript, so it should come as no surprise that many of these same designers have begun to learn JSP coding. Often, instead of just doing pure markup, they encode a complete JSP page and hand it over to the developer. Then the usual tweaking takes place, and the developer puts the JSP page into place as a front-end for some portion of the overall application. The key, though, is that manydesigners do not learn JSP coding, so it must also be workable in that environment.The problemsI've spelled out what a good presentation technology should provide, as well as the specific problems that JSP technology seeks to address. Now, I'm ready to cut to the chase: JSP technology, while built on good ideas, presents quite a few problems. Before you choose to use JSP coding in your applications (which you might still do), you should at least be aware of possible should also be aware of a facet of the J2EE programming platform that is often ignored: just because an API comes with the platform doesn't mean you have to use it. As silly as this sounds, many developers are struggling with the JSP, or EJB, or JMS APIs, thinking if they don't use these APIs, their applications somehow won't really be "J2EE applications." In fact, the platform boasts more APIs than most applications need. If you have problems with or doubts about JSP technology, you don't have to use it! Take a close look at both the positives and the negatives before choosing to use JSP technology in your applications. Let's take a look at some of the vs. language lock-inJSP technology locks you into a specific language. This point shouldn't be given too much weight. Java technology for enterprise applications (in my opinion, at least) is the only language choice. And there are no language-independent solutions in this space anyway. Of course, at this stage of the game, I'm disregarding the Microsoft .NET platform for the smoke and mirrors it is. Only time will tell whether that platform will develop into one that is truly language-independent. (I'm more than a bit dubious.)Still, choosing JSP technology forces you to use the Java language, at least for presentation and content. While CORBA can be used for business logic, JSP coding does necessitate some familiarity with servlets as well as the core Java language. Since many developers come to JSP coding through the J2EE platform, this doesn't usually present avs. independenceThroughout this article, I've come back to the idea of separating content from presentation. You're probably pretty sick of hearing about this, so now's the time to determine whether or not JSP actually accomplishes this goal. As I've already discussed, JSP claims to have been designed for this separation purpose, and therefore we should assume it achieves its objectives, right? Not the line between content and presentationJSP allows Java code to be inserted into the markup language page, and this rather dangerous feature allows content to be intermingled with presentation. Even worse, business logic often makes its way into JSP pages, as shown in Listing 5.class=displaycode<%@ page import="" %><%@ page import="" %><%@ page import="" %><%@ page import="" %><%@ page import="" %><%@ page import="" %><%PageInfo pageInfo = (PageInfo)("PAGE_DATA")%><HTML><HEAD><TITLE><%=()%></TITLE></HEAD><BODY><H2 ALIGN="center">Search Results: Actors</H2><CENTER><HR width="85%"><TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1"BGCOLOR="#FFFFCC"><%asPermission("ADMINISTRATOR")) {actors = ());} else {actors = ();}for (Iterator i = (); ()) {Actor actor = (Actor)();%><TR BGCOLOR="#FFCCCC"><TH width="50%" ALIGN="center"><%=()%></TH><TH width="50%" ALIGN="center"><%=()%></TH></TR><%}%></TABLE></CENTER></BODY></HTML>JSP advocates are quick to let you know that JSP tag libraries can help you avoid this problem. Tag libraries allow custom tags (for example, <AUTHORS />) to be added to a JSP page, which at runtime are resolved intocode fragments in, well, tag use of a custom tag and associated tag library would allow the example above to be converted to that shown in Listing 6.class=displaycode<CENTER><TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1"BGCOLOR="#FFFFCC"><ACTORS /></TABLE></CENTER>At runtime, the code for this tag executes and the correct results are inserted into the page. But this does not solve the problem. The argument against JSP technology is not whether content and presentation can be separated, but whether they must be separated. As long as JSP coding allows inline coding, it is very convenient (especially when deadlines are looming) to make last-minute changes with inline code, rather than converting the code to a tag library. If this doesn't ring true, consider why the Java language immediately gained popularity over C and C++: Java disallowed many of the features that were problematic in C, such as pointer addition. While you can always argue that you don't have to perform pointer addition in C or that no good programmer would ever insert code scriptlets, we all know what happens in practice. The Java language is a better language because it mandates that these sorts of bad habits never surface. But JSP in this case is much like C, allowing some very bad additional litmus test of the JSP technology's success in meeting its stated objectives is to see whether or not it is possible to achieve this goal in practice; certainly it isn't fair to hold JSP to an impossible standard. Most template engines, like FreeMarker and WebMacro, have this same inline coding facility, often with a Perl-analogue language. However, technologies like Enhydra's XMLC do not allow this type of inline coding.Instead, these technologies take a pure markup language page as input, and generate Java methods. This essentially is changing the program flow; instead of the page (JSP technology) calling logic from the application, the application (Enhydra) uses methods to affect the values of the page. In the specific case of Enhydra, XMLC converts the page into a DOM tree, and uses the DOM's HTML binding to allow "fields" in the page to be updated. The point here is that more so than XMLC, JSP technology can achieve its goals, by only allowing tag libraries, for example. But the general tendency in Sun specifications is to always maintain backward compatibility, or at least maintain it for quite a long time. The current version of the JSP spec, , allows scriptlets, so expect to see code allowed in JSP pages for several years to come. Before diving into JSP coding, be careful of the rather large hole that lies between its ideal, a complete separation of content and presentation, and what it actually provides, which is at best a pseudo-split between your user interface and the code that drives your application.Single-processing vs. multi-taskingIdeally, as discussed above, a designer ought to be able to perform a single process, working purely on graphic design, and a developer should be able to focus purely on coding. So the designer should be able to work on a page after it has been converted to an application-suitable format. In the case of a JSP page, that would be after JavaBeans have been imported, inline coding has been inserted, and custom tag libraries have been added to the page. The problem is that some designers use HTML editors, such as HoTMetaL, Macromedia Dreamweaver, or FrontPage, that do not recognize code scriptlets or tag libraries, which means the designer effectively receives only a partial page. Imagine the difficulties when tag libraries or code fragments generate rows of a table, or other formatting detailsfor the page. Designers using the incompatible HTML editors can't see what those elements look like. When designers can't easily revise pages after developers finish coding them, instead of clarifying distinct roles, JSP coding can cause them to merge: a developer must multitask, becoming developer, designer, and about the importance of this feature? Then download the J2EE Reference Implementation and load one of the included JSP pages into a WYSIWYG HTML editor, such as Dreamweaver. The page immediately fills with yellow areas letting you know about all the "illegal" markup contained within the page. Of course, the yellow results from the JSP tags and code, rather than any real error in the date, no JSP-capable WYSIWYG editors exist, and I have not heard of any efforts to build one. While template engines have this same problem, many Java-based solutions, such as my favorite, Enhydra, allow you to supply the markup page as input to the presentation technology. In this case, the designer can make changes as often as needed and resupply the markup page. Running the engine or compiler for the presentation technology converts it to the proper format, and no code changes have to be made (in the typical case). The result is the desired one: designers remain designers, and developers remain , be wary of the promise of JSP technology as compared to the reality of what it delivers. In practice, to function in a JSP technology-driven environment you must either have your developers handle a large portion of the markup or have designers learn at least some JSP vs. XMLOne of the most significant disadvantages of JSP technology, and one of the most overlooked, is its incompatibility with XML. More precisely, and particularly in the HTML realm, JSP pages are not required to be XHTML-compatible. XHTML is a World Wide Web Consortium (W3C) specification that is now replacing HTML . XHTML defines the HTML tagset in terms of a well-formed XML document. For example, the <br> tag must be converted to <br/> to ensure XML compliance. Similar rulesare applied to image tags, and in XHTML (recently coming of age) most font properties and other styling move into CSS stylesheets. Still, most standard HTML documents convert easily to XHTML , which means they can be read directly with any XML-compliant parser, such as Apache Xerces, and manipulated as XML."What's the big deal?" you ask. The big deal is that XML quickly is becoming the global standard for inter- and intra-application communication. Passing data around in an XML format lets any other application that employs basic XML data-handling facilities use your application's data easily. Imagine being able to communicate with credit card companies for e-commerce simply by moving your data into an XML format! Many times, your presentation of data needs to be exchanged with other companies as well. The most common case is the portal application, which receives content from a variety of providers (weather, stock quotes, and news, for example), often with branding from the provider. JSP pages, however, with their mix of code and custom tag libraries, cannot function well in this pages are rarely well-formed XML documents, never mind conforming to XHTML, a markup language that doesn't allow the various JSP custom tag libraries. More important, though, is that the code snippets inserted in JSP pages are not any form of markup and will create loads of parser errors once they are processed by another you go quoting me on this, let's get the whole story out there. If the application were to allow the JSP page to be evaluated by the original client, the result would be pure HTML (or WML, VoXML, and so on). Most applications that request this data, however, employ some form of caching, as network round-trips are very expensive. In these cases, the cached page returns stale data. In those cases, then, you'd probably prefer to return pure XML-compliant results, preferably in a static form. And it is in those cases that JSP technology cannot help; JSP pages must always be evaluated at runtime to remove the JSP code scriptlets and tag the litmus test:。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
JSP技术Java Server Pages(JSP)是一种基于web的脚本编程技术，类似于网景公司的服务器端Java脚本语言—— server-side JavaScript(SSJS)和微软的Active Server Pages(ASP)。
与SSJS和ASP相比，JSP具有更好的可扩展性，并且它不专属于任何一家厂商或某一特定的Web服务器。
尽管JSP规范是由Sun公司制定的，但任何厂商都可以在自己的系统上实现JSP。
在Sun正式发布JSP(Java Server Pages)之后，这种新的Web应用开发技术很快引起了人们的关注。
JSP为创建高度动态的Web应用提供了一个独特的开发环境。
按照Sun的说法，JSP能够适应市场上包括Apache WebServer、IIS4.0在内的85%的服务器产品。
本文将介绍JSP相关的知识，以及JavaBean的相关内容，当然都是比较粗略的介绍其中的基本内容，仅仅起到抛砖引玉的作用，如果读者需要更详细的信息，请参考相应的JSP的书籍。
1.1 概述JSP(Java Server Pages)是由Sun Microsystems公司倡导、许多公司参与一起建立的一种动态网页技术标准，其在动态网页的建设中有其强大而特别的功能。
JSP与Microsoft的ASP技术非常相似。
两者都提供在HTML代码中混合某种程序代码、由语言引擎解释执行程序代码的能力。
下面我们简单的对它进行介绍。
JSP页面最终会转换成servlet。
因而，从根本上，JSP页面能够执行的任何任务都可以用servlet来完成。
然而，这种底层的等同性并不意味着servlet和JSP 页面对于所有的情况都等同适用。
问题不在于技术的能力，而是二者在便利性、生产率和可维护性上的不同。
毕竟，在特定平台上能够用Java编程语言完成的事情，同样可以用汇编语言来完成，但是选择哪种语言依旧十分重要。
和单独使用servlet相比，JSP提供下述好处：JSP中HTML的编写与维护更为简单。
JSP中可以使用常规的HTML：没有额外的反斜杠，没有额外的双引号，也没有暗含的Java语法。
能够使用标准的网站开发工具。
即使是那些对JSP一无所知的HTML工具，我们也可以使用，因为它们会忽略JSP标签（JSP tags）。
可以对开发团队进行划分。
Java程序员可以致力于动态代码。
Web开发人员可以将精力集中在表示层（presentation layer）上。
对于大型的项目，这种划分极为重要。
依据开发团队的大小，及项目的复杂程度，可以对静态HTML和动态内容进行弱分离（weaker separation）和强分离（stronger separation）。
此处的讨论并不是说人们应该放弃使用servlet而仅仅使用JSP。
事实上，几乎所有的项目都会同时用到这两种技术。
在某些项目中，更适宜选用servlet，而针对项目中的某些请求，我们可能会在MVC构架下组合使用这两项技术。
我们总是希望用适当的工具完成相对应的工作，仅仅是servlet并不一定能够胜任所有工作。
1.2 JSP的由来Sun公司的JSP技术，使Web页面开发人员可以使用HTML或者XML标识来设计和格式化最终页面。
使用JSP标识或者小脚本来生成页面上的动态内容(内容是根据请求来变化的)。
Java Servlet是JSP技术的基础，而且大型的Web应用程序的开发需要Java Servlet和JSP配合才能完成，Servlet这个名称源于Applet，现在国内的翻译方式很多，本书为了避免误会，决定直接采用Servlet而不做任何翻译，读者如果愿意，可以称之为“小服务程序”。
Servlet其实和传统的CGI、ISAPI、NSAPI等Web 程序开发工具的作用是相似的，在使用Java Servlet以后，用户不必再使用效率低下的CGI方式，也不必使用只能在某个固定Web服务器平台运行的API方式来动态生成Web页面。
许多Web服务器都支持Servlet，即使不直接支持Servlet的Web 服务器也可以通过附加的应用服务器和模块来支持Servlet。
得益于Java的跨平台的特性，Servlet也是平台无关的，实际上，只要符合Java Servlet规范，Servlet 是完全与平台无关且是与Web服务器无关的。
由于Java Servlet内部是以线程方式提供服务，不必对于每个请求都启动一个进程，并且利用多线程机制可以同时为多个请求服务，因此Java Servlet效率非常高。
但Java Servlet也不是没有缺点，和传统的CGI、ISAPI、NSAPI方式相同，Java Servlet是利用输出HTML语句来实现动态网页的，如果用Java Servlet来开发整个网站，动态部分和静态页面的整合过程会非常难以实现。
为了解决Java Servlet的这种缺点，SUN推出了JSP。
许多年前，Marty受到邀请,参加一个有关软件技术的小型研讨会.坐在Marty 旁边的人是James Gosling--- Java编程语言的发明者。
隔几个位置,是来自华盛顿一家大型软件公司的高级经理。
在讨论过程中,研讨会的主席提出了Jini的议题,这在当时是一项新的Java技术。
主席向该经理询问他的想法.他回答说,虽然现在言之过早，但这看起来会是非常有前途的一项技术。
他们会持续关注这项技术,如果这项技术变得流行起来,他们会遵循公司的“接受并扩充(embrace and extend)”的策略.此时, Gosling随意地插话说“你的意思其实就是不接受且不扩充(disgrace and distend)。
”在此, Gosling的抱怨显示出，他感到这个公司会从其他公司那里拿走技术,用于他们自己的目的.出人意料的是，形势已经完全不同。
Java团队并没有发明这一思想----将页面设计成由静态HTML和用特殊标签标记的动态代码混合组成.。
ColdFusion多年前就已经这样做了。
甚至ASP(来自于前述经理所在公司的一项产品)都在JSP出现之前推广了这种方式。
实际上,JSP不只采用了这种通用概念,它甚至使用许多和ASP相同的特殊标签。
JSP是建立在Java servlets模型之上的表达层技术，它使编写HTML变得更简单。
像SSJS一样，它也允许你将静态HTML内容与服务器端脚本混合起来生成动态输出。
JSP把Java作为默认的脚本语言，然而，就像ASP可以使用其他语言(如JavaScript和VBScript)一样，JSP规范也允许使用其他语言。
1.3 JSP的特点按照脚本语言是服务于某一个子系统的语言这种论述，JSP应当被看作是一种脚本语言。
然而，作为一种脚本语言，JSP又显得过于强大了，在JSP中几乎可以使用全部的Java类。
作为一种基于文本的、以显示为中心的开发技术，JSP提供了Java Servlet的所有好处，并且，当与一个JavaBeans类结合在一起时，JSP提供了一种使内容和显示逻辑分开的简单方式。
分开内容和显示逻辑的好处是，更新页面外观的人员不必懂得Java代码，而更新JavaBeans类的人员也不必是设计网页的行家里手，就可以用带JavaBeans类的JSP页面来定义Web模板，以建立一个由具有相似的外观的页面组成的网站。
JavaBeans类完成数据提供，这样在模板中就没有Java代码，这意味着这些模板可以由一个HTML编写人员来维护。
当然，也可以利用Java Servlet来控制网站的逻辑，通过Java Servlet调用JSP文件的方式来将网站的逻辑和内容分离。
一般来说，在实际的JSP引擎中，JSP页面在执行时是编译式，而不是解释式的。
解释式的动态网页开发工具如ASP、PHP3等由于速度等原因已经满足不了当前大型电子商务应用的需要了，传统的开发技术都在向编译执行的方式改变，如ASP →ASP+；PHP3→PHP4。
在JSP规范书中，并没有明确要求JSP中的程序代码部分(称为Scriptlet)一定要用Java来写。
实际上，有一些JSP引擎就是采用的其他脚本语言，如EMAC-Script、WebL等，但实际上这几种脚本语言也是构建在Java上面，编译为Servlet来实现的。
按照JSP规范书写，和Java没有任何关系的Scriptlet也是可以的，不过，由于JSP的强大功能主要在于能和JavaBeans、Enterprise JavaBeans 共同运转，所以即使是Scriptlet部分不使用Java，编译成的执行代码也应该是与Java相关的。
1.4 JSP的机制要理解JSP怎样联合以上各种所提到的技术的优点，从而轻而易举地实现各种效果，用户必须首先了解“组件为中心的网页开发”和“页面为中心的网页开发”的区别。
都SSJS和ASP都是在几年前推出的，那时网络还很年轻，没有人知道除了把所有的商务、数据和表达逻辑统统堆进原始网页中之外还有什么更好的解决方法。
这种以页面为中心的模型容易学习并且得到相当快速的发展。
然而，随着时间的推移，人们认识到这种方法不适于构建大型的、可升级的Web应用程序。
在脚本环境中书写的表达逻辑被锁在页面内，只有通过剪切和粘贴才能被重用。
表达逻辑通常和商务及数据逻辑混在一起，这使得当程序员试图改变一个应用程序的外观而不想破坏与之紧密结合的商务逻辑时，应用程序的维护就变得十分艰难。
其事实上，企业中可重用组件的应用早已经很成熟，没有人愿意为它们的应用程序重写那些逻辑。
HTML和图形设计师把它们的设计的实施工作交给了Web编写者，使他们不得不加倍工作——常常是手工编写，因为没有合适的工具可以把服务器端脚本与HTML 内容结合起来。
简而言之，随着Web应用程序的复杂性不断提升，以页面为中心的开发方式的局限性变得明显起来。
与此同时，人们一直在寻找建立Web应用程序的更好方法，组件在客户机/服务器领域流行起来。
JavaBeans和ActiveX被“快速应用程序开发”(RAD)工具发行商推广给Java和Windows应用程序开发者用来快速开发复杂的程序。
这些技术使某领域内的专家可以为本领域内的垂直应用编写组件，而开发者可以直接拿来使用而不必掌握这一领域的专门技术。
作为一种以组件为中心的开发平台，JSP出现了。
它以JavaBeans和Enterprise JavaBeans(EJB)组件包含商务和数据逻辑的模型为基础，提供大量标签和一个脚本平台用来在HTML页中显示由JavaBeans产生或回送的内容。
由于JSP的以组件为中心的性质，它可以被Java和非Java开发者同样使用。
非Java开发者可以通过JSP的标签(Tags)来使用高级Java开发者创建的JavaBeans。