![]()
|
||||||||||||||||||||||||||||||||||||||
FormGenerator Part 2 : How to check inputs from CGI FORM / XHTML, WML or SVG by JSP / Japanese Shift_JIS, Chinese BIG5, GB2312 or Russian KOI8-R
How to check input of CGI FORM by JSP/Servlet on Apache Tomcat. XHTML, HDML/WML (WAP) or SVG by XML. Ready for Japanese Shift_JIS, Chinese BIG5, GB2312 or Russian KOI8-R. Better than JSP or XSLT.
Related Pages:
|
||||||||||||||||||||||||||||||||||||||
Very basic concept:
In this section, we will show you the very basic of this Java API. To make the things easier, the example in this section is meaningless.
But, please don't be impatient.
Later, you will see more interesting features.
In the JSP/Servlet programming by this Java API, the static code fragments can be written to the XML. Then, you can insert the arbitrary String between the code fragments. By d.value element in the XML, you can specify where to insert the String.
The XML must comply with: . This DTD is abstract enough to store the code fragments for any type of mark up language, such as HTML, XHTML, HDML, WML and SVG. Please place the XML under:
In the above example, the HTTP request is forwarded to another JSP along with the request-scope attribute. On the destination JSP, the generated HTML tag is available and can be merged into its own response. This is just the very basic of this Java API. In the subsequent sections, we will describe the powerful features of this Java API.
One more basic:Please be patient for a bit while. This section describes another basic of this Java API. It is...
For example, to insert Hello between the 2 code fragments for valid case, JSP/Servlet can call:
How to check input from CGI FORM:
First of all, the code fragment for the intended CGI FORM can be written in the XML.
In the departing JSP, the tags for the CGI FORM will look like:
If the user types "123" and sends the request to the Servlet, the input is invalid. And the tags for the CGI FORM like below should be generated, as the response from the destination Servlet:
As shown in the previous section, the arbitrary String can be inserted into the code fragments. Moreover, the 2 set of code fragments can be written in the XML, one for the valid case and another for the invalid case. So, the following XML will be enough for generating both of the above HTML tags:
Because the above CGI FORM includes only one text field, the destination Servlet can easily check the validity of the parameter value. Then, you can guess the remaining tasks of the destination Servlet. (If you cannot, please read the previous section again.) But, the CGI FORM in the real world includes more than one text field. Don't worry. This Java API takes care of you. As you know, the java.util.Map interface includes a set of key-value pairs. Similarly, each instance of HttpServletRequest has a set of the HTTP request parameters from the departing CGI FORM. From the instance of HttpServletRequest, you can get the parameter value for the specified parameter name. Form class implements the very useful method. It is:
First, this methods list all the character data within d.value elements of the intended XML. In this method, each character data within d.value element is considered as the parameter name of the HTTP request. In this step, the duplicate parameter name will be ignored. Then, for each parameter name, it tries to find the corresponding parameter value in the given instance of HttpServletRequest. If found, the parameter value will be inserted into the code fragments. In this step, the validity of the parameter value is determined. By verify.type attribute of that d.value element, you can specify which type of parameter value is valid. Please look into the source XML listed below:
In this example, the parameter value only with a-z or A-Z can be treated as valid. For example, if the parameter value includes any of 0-9, it is treated as invalid. Based on the validity of the parameter value, this method selects the appropriate code fragments. In case that the parameter value is not found in the HttpServletRequest, the empty String will be inserted into the code fragments. The validity of this empty String depends on not.null attribute, i.e. if YES is specified there, the empty String will be treated as invalid. After the above method, JSP/Servlet can see if all the parameter value are valid or not, just by:
In case that every parameter value is valid, JSP/Servlet should proceed to the next step. JSP/Servlet may save the parameter values into SQL table through JDBC PreparedStatement, or it may send the e-mail by JavaMail API. It fully depends on your web application. On the contrary, most of the JSP/Servlet should do the same thing, if any of the parameter value is invalid. Yes, JSP/Servlet should show the same CGI FORM again to ask the user to enter the correct input. It is desirable for this CGI FORM to include all the previous input as the default values. In addition, this CGI FORM should indicate which text field include the invalid input. Then, the users can easily fix some of their previous inputs and send them again. The good news is... The HTML tags for such a complex CGI FORM is already available on your hand! All you have to is to call:
Thus, a few lines of code are enough for checking all the inputs from the CGI FORM. The implementation of FormValueVerifier interface is responsible for checking the validity of the input from the CGI FORM. Its fully qualified class name must be listed in:
To satisfy your requirement, you can easily define your own implementation of FormValueVerifier interface. Please look into the source code listed above. Because a lot of frequently used methods are already defined in the abstract class (AbstractVerifier), all you have to do is to call some of them within your subclass. In case of JDK 1.4 (J2SDK 1.4), thing can be much easier by the benefits of java.util.regex package (the new API for pattern matching by regular expressions). For example, a few lines of codes are enough for IsEmailAddress and IsJpPostalCode.
XML selection based on Locale:
Most web browsers (or WAP browsers) allows the users to select their preferable languages.
When the web browser (or WAP browser) sends the HTTP request, the language preference is also sent as one of the header information.
On the server side, this language preference can be used to send back the localized contents.
For example, Apache HTTPD server (so called Apache web server) implements content negotiation, which selects the localized HTML file based on the language preference.
If the user prefers French language, the HTTP request will be forwarded to the JSP in French language. Otherwise, the JSP in English will be shown. If you'd like to add the localized contents in Japanese language, what do you do? Please note the next source does not work:
Because you cannot prepare the JSP for all the possible languages in the real world, the above Servlet may result in 404 (not found) error. Yes, whenever the additional localized contents is added, you will need to slightly modify the above source. Or, you should list all the available JSP in the property file, with the corresponding language code as the key. With this Java API, the things can be much simpler. Form class implements:
All you have to do is to prepare the XML for the expected Locales. You should take the great care for the file name of XML, because this method tries to find the XML based on:
The language code is lower-case 2-letter code as defined by ISO-639. You can find a full list of these codes at a number of sites, such as: The country code is upper-case 2-letter codes as defined by ISO-3166. You can find a full list of these codes at a number of sites, such as: For example, if the first parameter of this method is foo and the second one (the instance of Locale) indicates:
Let's look into the Servlet below:
Assuming that you'd like to prepare the localized contents for French and English, you will need to write the following XML:
As you see in the above source code, the XML can have the element for Content-Type. For example, the first XML in the above list may look like this:
And the second one (and the last one) will be:
Because the contents both in French and English can be represented by ISO-8859-1 charset, these 2 XML has the same content.type element, which specifies the Content-Type header followed by the charset extension for ISO-8859-1. But, if you'd like to add the Japanese contents, its source XML (hello_jp.xml) will be something like:
Please note the content.type element in this XML. The character data within this element is the Content-Type header, which is followed by the charset extension for Shift_JIS. By the way, if your boss suddenly asks you to add the Japanese contents, what do you do? All you have to do is to place the above XML. You need not touch your existing source code at all, and can have a nice week end. Thus, this JSP/Servlet API makes your web application truly internationalization (i18n) ready.
How to escape the special characters:
As described in the previous sections, you can insert the arbitrary String into the pre-defined code fragments.
Then, the instance of Form can merge them all and return the concatenated String.
Then, the corresponding implementation will be used to escape the String to be inserted. The implementation of this interface must implement:
The special characters to be escaped differ with the mark-up-languages. In case of HTML, at least the following characters should be escaped:
In addition, " and $ should be also replaced with " and &dol; in HDML. In XML, the following characters should be escaped:
As for WML, $ should also be replaced with $$. (See Page 6 of WML Language Reference which is available at OpenWave's web site.) Anyway, the 4 implementations are included in this package. They are: So, please feel free to use any of them. Or, if you need additional features, you can define your own implementation which satisfies your requirement. In this case, please add the fully qualified class name of your implementation to:
Occasionally, you may want to URL-encode the String to be inserted. This JSP/Servlet API also includes: which is another implementation of FormValueEscaper interface. By this implementation, the String to be inserted is URL-encoded before it is inserted into the code fragments. Note that the above implementation uses ISO-8859-1 (US-ascii) as the charset. In addition to ISO-8859-1 (US-ascii), the implementations for UTF-8 and Shift_JIS are also included in this API. They are:
Please look into the source codes of these 2 classes. As you notice, they are the subclass of which override the value of: protected String charset="ISO-8859-1";in their constructors. In this way, you can easily add your own implementation for your requirement.
Line breaks within HTML, HDML, WML or XHTML:
As described in the previous sections, you can insert the arbitrary String into the pre-defined code fragments.
Then, the instance of Form can merge them all and return the concatenated String.
The implementation of this interface must implement:
The tags for line break differ with the mark-up languages. In case of HTML and HDML, it is <br>. As for WML and XHTML, <br /> should be used instead. To be ready for both of them, the 2 implementations are included in this package. They are: So, please feel free to use any of them. Or, if you like, you can define your own implementation which satisfies your requirement.
Download:
-- 230.00 USD with 1 year FREE upgrade
You can try or purchase this product at Java API Shop by OOP-Research.
|
|
|||||||||||||||||||||||||||||||||||||
|
Java and all Java-based trademarks and logos are trademarks or registered of Sun Microsystems, Inc. in the United States and other countries. |
||||||||||||||||||||||||||||||||||||||
|
ALL CONTENTS COPYRIGHT 1997-2007, OOP-Research Corporation. All rights reserved. |
||||||||||||||||||||||||||||||||||||||