公交信息查询系统的设计与实现 英文翻译-.doc

URL-Related ActionsObviously the ability to import, link, and redirect is fundamental in any JSP-based web application. The JSTL provides several useful URL-related actions to simplify these requirements.The ActionThis action imports the content of a URL-based resource and provides a simple, generic way to access URL-based resources that can either be included or processed within the JSP page.You can see a good example of the action at work as it works with some of the actions from the XML library, which, of course, require an XML document to work with. The action is the simplest way to retrieve a file containing XML or XSLT, which is then used by subsequent XML action for processing. For example:Here you can see how the action is used to retrieve a file called book.xml from a remote location, which is then utilized by the action from the XML tag library. Note that in this case, because of the presence of the var parameter, the actual contents of the file arent written to the current JspWriter but are instead stored in the named parameter.The action can also be used to specify absolute, relative, foreign, context-relative, and FTP URL resources to provide a lot more functionality that the standard action youre so used to having.The ActionThe action provides a handy way of constructing correctly formatted URLs that have the correct URL rewriting rules applied.As youre no doubt aware, without session tracking or the ability to recognize a number of requests from the same user, the majority of complex web-based applications wouldnt be functionally possible due to the statelessness of the HTTP protocol. Generally, browsers provide the session-tracking mechanism by storing cookies (small text files stored on the client machine), which are sent back with each request the client makes during a “session.” Because most modern browsers enable the user to disable cookies(usually for security reasons), its very important to ensure that any URLs that your web applications use are URL-rewritten to ensure that their session-tracking capabilities are maintained if cookies are disabled.A rewritten URL looks something like this:As you can see, the actual rewriting of a URL simply involves appending a special value to the end of the query string, which is used to track requests that originate from the same user. These requests are therefore part of the same session.Previously, JSP scritplets were typically used to ensure that all URLs were rewritten by calling the encodeURL() method provided by the HttpServletResponse interface.The action takes care of all the URL rewriting on your behalf without the need for any scriptlet code! For example, to encode the URL, all thats required is the following:The ActionAs the same suggests, the action simply sends an HTTP redirect to a client.For example, to redirect a user to perhaps an updated site or a moved application, the action is used as follows:Its as simple as that! The action does also support the use of another optional attribute called context, which can be used to identify the name of a context when redirecting to a relative URL that belongs to a foreign context. In more simple terms this means that you can actually forward the request to another web application hosted inside the same container!The ActionThe , , and actions all deal with URLs and as youre probably aware its pretty common to pass request parameters as part of URLs by appending them to the query string.The action is designed solely for this purpose and may be used as a nested tag in the body content of either the , , or actions. The action takes two very simple attributes, name and valuel, which simply represent the same of the request parameter along with its value, respectively. Note also that the value of the name and value attributes are URL encoded by default.For example:Like many of the JSTL actions, the action can be used in two forms, first as shown previously, and second, whereby the value for the parameter is given inside the body content of the action itself. Lets take a look at the previous example using the alternative format:The Internationalization and Formatting Tag LibraryPreparing an application so its ready for the global marketplace is known as internationalization (or I18n for short). A related term, localization (or l10n), refers to the process of customizing an application for a particular language or region.The popularity of the Internet has enabled organizations to vastly increase their exposure and client base by exposing their services via dynamic web applications. Ensuring that clients from around the world can interact with such applications using their native language and conventions has never been more important.The Internationalization and Formatting tag library provided by the JSTL provides a set of simple actions to aid this process and make use of the three key components associated with internationalization: locales, resource bundles, and base name.Setting the LocaleThe Internationalization and Formatting tag library provides a number of actions that allow you to control the locale settings for your JSP pages.The actionAs the name suggests, this action can be used to override the client-specified locale for the processing of a JSP page. Any I18n formatting actions such as that are found on the page will use this specified locale instead of the one sent by the client browser.The chosen locale is stored in a variable called javax.servlet.jsp.jstl.fmt.locale and can ben stored in any chosen scope.This JSP code first sets the default locale for the page followed by the session:The value attribute accepts either a string representing the locale (a two letter, lowercase language code followed a two letter, uppercase county code), or a reference to a java.uitl.Locale object.Note that its also possible to set a default locale for use via the JSTL using the following configuration setting in the web applications deployment descriptor (web.xml):As you can see, this configuration establishes English as the default locale for the application.Important An important point to note is that the action overrides the browser-based locale setting. Therefore, if you use this action, make sure its placed at the beginning of a JSP page before any I18n formatting actions.Messaging ActionsOnce the locale has been defined for a client request, either by the clients browser settings or use of the action, the JSTL messaging actions can be used to display content to the client in its own language as identified by its locale.To take advantage of localized messages, its necessary as a developer to provide a collection of resources (usually strings) for each locale that you intend to support. Each collection of resources is known collectively as a resource bundle and is implemented via a standard key = value properties file. For more information, take a look at the Java 2 Platform, Standard Edition (J2SE) Javadocs for the java.util.ResourceBundle class.The and ActionTo enable the use of localized messages its necessary to specify the required resource bundle that provides the localized messages.Either the or actions can be used to specify a resource bundle, and theyre identified by the basename to be used in the JSP page. Once successfully declared, the resource bundle can then be used to provide localized messages via the action, which youll see shortly.Although similar, the and actions are used in different ways to produce localized messages in JSP pages.The action is used to declare an I18n localization context for use by I18n-aware tags within its body content:Here, a resource bundle with the name Labels is declared to provide the localized resources for any nested actions.Due to the fact that the action is designed to work so closely with nested actions, a handy optional attribute can also be used as follows:As you can see, the optional prefix attribute enables the setting of a predefined prefix that is prepended to the key attribute of any nested actions, which makes their use so much simpler.The action also provides similar functionality to those you just saw, but with a subtle difference. Instead of having to nest any actions as body content, the action enables a resource bundle to be stored in the configuration variable javax.servlet.jsp.jstl.fmt.localizationContext, so any actions that appear elsewhere in the JSP page can access the bundle without having to continually declare it as following:The action also enables you to declare the exported variable that stores the bundle along with its scope. This flexibility makes it simple to use multiple bundles within the same JSP interchangeably.Note that the JSTL does provide a mechanism to set a default resource bundle for a web application via the following configuration setting in the applications deployment descriptor (web.xml);The ActionAs mentioned earlier, localized messages are retrieved from a resource bundle using the action, which uses a key parameter to extract the message from the resource bundle and print it to the current JspWriter.Youve also seen that the action can be used by itself on a page or as body content to the action. Should you wish to use the action by itself you can specify via optional bundle attribute the resource bundle to use. This can be the default configured bundle or a localization content that has been configured and stored in a separate variable by the action.Another optional parameter, var, enables the localized message to be stored in a parameter instead of being printed to the JspWriter. As with most of the JSTL tag, the scope of this variable can be set using the scope attribute.Lets build a simple working example to demonstrate the , , and tags working together to create a localized JSP page.Your first task is to set up the locale-specific resources, and in this case youre simply going to localize some simple strings by utilizing a resource bundle. There are several ways in which a resource bundle can be created, but the most simple involves building a list of name-value pairs representing the locale-specific resources that you wish to externalize from the application code. Lets localize some simple strings and provide implementations in both English and Spanish.Here youll localize four strings whose name-value pairs are stored on the class path (under the WEB INF/classes directory, for example) in a file called labels_perties. This file will be the English resource bundle for the localization-aware JSP. Next lets provide another resource bundle, this time in Spanish:As you can see, the names stay the same but this time the values are in Spanish! This bundle must be placed in a file called labels_perties.Now that you have the resource bundles in place you can code the localized JSP:This JSP simple sets the locale to be en_GB and configures the resource bundle using the action along with the bundle basename called labels.The rest of the JSP simple builds a small HTML form that asks the user to input some information about herselft. Notice how you have localized the labels for the form input fields using the action.Not surprisingly, when you run this code, the locale is set to en_GB and the appropriate resource bundle is loaded. With the help of the actions, the following page is built:To demonstrate that the page is supported in both English-speaking countries as well as Spanish-speaking countries, you simply have to change the followingline of code:Of course in the real world, the locale is usually retrieved from a special header that is send by the clients browser during the initial request. The only reason we explicitly set the locale here is to demonstrate how the JSP would work in a Spanish-speaking country. The output is as follows:Formatting ActionsEnsuring that your clients view your JSP pages in their own language is just the tip of the iceberg with regard to building a fully internationalized and localized application. In addition to language, users from different locales have different standards regarding the following:n Date and time formatsn Number formatsn Currency formatsn Colorsn Page layoutsn Address standards (zip code)Luckily, to make your job easier, the formatting tag library provided by the JSTL enables various data elements in a JSP page, such as numbers, dates, and times, to be formatted and parsed in a locale-sensitive or customized manner.The and ActionsDate-and-time information on a JSP page can be displayed in a manner consistent with the preferred time zone of a client. This is enormously useful if your server that hosts the page and the client reside in different time zones. The JSTL provides two actions to enable any I18n-aware date-and-time actions to format or parse their date-and-time information in an appropriate manner.The and actions complement each other in a similar fashion as the and actions introduced earlier. The action is used to specify a TimeZone for any nested I18n-aware actinos that appear inside its body content whereas the can be used to store a reference to a TimeZone in an exportable variable for use anywhere on a JSP page.The action is simply used as follows:As you can see, a single attribute called value is used to specify the time zone, which can either be a java.util.TimeZone object or a string that represents one of the time zone IDs supported by the Java platform (such as “America/Los Angeles” or a custom time zone such as “GMT-8”).The action is used as follows:This action enables a java.util.TimeZone object to be stored in a scoped variable that can be utilized by any I18n-aware actions such as the and actions, which youll see