【正文】 hat 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 doesn39。t provide any capabilities that couldn39。t, in principle, be acplished 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 can39。t understand how JSP works without understanding servlets.2. JSP consists of static HTML, specialpurpose JSP tags, and Java code. What kind of Java code? Servlet code! You can39。t write that code if you don39。t understand servlet programming3. Some tasks are better acplished 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 acplished by a bination of servlets and JSP than by either servlets or JSP JavaScript JavaScript, which is pletely 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 peting technology。 it is a plementary 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 munity that draws from many different panies. So, the technology can incorporate improvements in successive releases However, some groups have developed alternative Javabased technologies to try to address these deficiencies. This, in our judgment, is a mistake. Using a thirdparty tool like Apache Struts that augments JSP and servlet technology is a good idea when that tool adds sufficient benefit to pensate for the additional plexity. 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 JSPpatible 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 expression language address two of the most wellfounded 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 JSPForgetting JSP Is ServerSide TechnologyHere are some typical questions Marty has received (most of them repeatedly)? Our server is running JDK . So, how do I put a Swing ponent in a JSP page?? How do I put an image into a JSP page? I do not know the proper Java I/O mands 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 serverside process. But they do not. Thus:? For putting applets with Swing ponents into Web pages, what matters is the browser39。s Java version—the server39。s version is irrelevant. If the browser supports the Java 2 platform, you use the normal APPLET (or Java plugin) tag and would do so even if you were using nonJava 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 (., two levels up from WEBINF/classes) and output a normal IMG tag? You create images that change under the mouse by using clientside JavaScript, referenced with the SCRIPT tag。 this does not change just because the server is using JSP? Browsers do not support JSP at a