servlet| Dynamic | control | graphics Control the world-or at least control your image
As a site developer or page author, it is difficult to cater to all of these preferences. To do this manually, you must convert each image on the site to the size of the image supported by your Web site. Then, you need to adjust the image markers on each page in the site so that each tag correctly reflects the size of the image. You cannot change the width (width) and height (height) of the HTML img tag only, without changing the image: This causes the low-bandwidth user to download the large image and resize it on the client side. If you provide eight commonly used image sizes, it is easy to see how each image will require eight zoom sizes, and how each page will require eight versions of the image tag. This type of image management is tedious and error-prone, and it's easy to see why most Web sites don't offer multiple image sizes.
The problem is not technology: it is easy to use Java programming to convert images into various sizes or formats. The problem is not the service: it is common to use WEB servers to tailor pages to meet the needs of individual readers. Instead, the problem is to combine technology and services in a form that is easy to deploy and manage.
This article recommends a solution that uses the JavaServer Pages (JSP) tag to manage your images. For example, instead of encoding an image tag in HTML and providing multiple versions for each image size, like the following:
It is more meaningful to provide a marker that automatically adjusts the size of the image based on reader preferences, as follows:
<util:imagesizer src= "Http://www.163design.net/j/f/images/LazyDog.jpg"/>
It is possible to have readers choose from a number of sizes and have their preferences affect all images on the site, as shown in the sample browser image in Figure 1. It is also possible to insert wide and high attributes and eliminate the drudgery of manually editing these tags.
Figure 1. Sample JSP page with image preferences (laugh one)
Perhaps you've never seen a JSP custom tag before, let's take a quick look at the syntax in this example. JSP custom tags look very much like HTML tags, but have the following differences:
There is a tag name Imagesizer created by the markup developer.
The tag has a prefix util that combines the set of tags into a library, much like the package name in Java programming. You can create a new prefix, or use the default name that is provided with the library.
The tag has a new, XML-like end tag "/>".
As with HTML tags, JSP tags can have any number of properties, such as the SRC attribute shown here, which can contain principals and other tags in the body. Since we are imitating the HTML img tag, our JSP image scaling tag will have no body.
When a JSP page uses a custom image-sizer tag, the markup Java implementation finds the image file, converts it to the appropriate size (in which case a copyright or watermark logo may be added), and then provides the image to the reader. This tag makes it unnecessary for the site manager to convert images before publishing. It also simplifies the work of writing Web pages, because processing many image size preferences requires only one page. Finally, and most importantly, providing this kind of flexibility for all your site images will win the reader's favor.
What happens on the WEB server
This section provides a high-level view of what is happening behind the scenes when a client (a Web browser used by readers) accesses a site that provides JSP pages. There are three common types of interactions, as shown in Figure 2:
Figure 2. Interaction between the WEB client and the server
In the first case, assume that the browser requests only static documents, such as HTML files or image files. The server finds resources in its file space and then provides the file to the browser. Request documents and response requests are defined in HTTP, and HTTP forms the basis of client/server interaction on the Internet. The Web server processes the request completely without interacting with the servlet container or the WEB application server.
In the second scenario, assume that the browser requests a WEB resource that contains a Java servlet. The Java servlet enables the Web server to perform tasks on the server using the Java programming language. The servlet is effective and uses less memory and processing power than the old technologies, such as Common Gateway Interface (CGI), server-side JavaScript. The servlet is more portable than other technologies because many WEB servers, such as IBM WebSphere Application Server (Application Server) and Apache Tomcat, support the servlet container, and The servlet container can run the same servlet on many different platforms. Finally, because of the inherent security of the Java language (such as robust exception handling and fine-grained security), the wrong servlet rarely affects the WEB server. As shown in Figure 2, the WEB server searches for the appropriate servlet, compiles the servlet source code if necessary, and then returns the results of the servlet's processing to the requester. The frequently requested servlet is cached in the server's memory.
In the third scenario, assume that the browser requests a Web page that contains a JSP page. JSP pages help simplify the task of displaying information and help separate dynamic content (live generated) from static pages. The Web page designer uses JSP tags like any other tag in the HTML library. The JSP programmer follows the JSP programming specification and implements the markup according to its conventions.
The next section explains how to implement image scaling JSP tags and how to write JSP pages. From a Web container standpoint, JSP pages are closely related to the Java servlet. The Web container converts a text-based JSP page into its Java implementation (once per page). The Web container looks for a Java implementation, regards the implementation as a Java servlet, runs the code, and returns the processing results to the client. These look like there are many layers and redirects, but for the user, the dispatch is quick and transparent. Like a servlet, JSP pages that are often requested are cached in the server's memory.
