The markup language for WAP is WML (Wireless Markup Language).
The syntax of WML is the same as XML, and WML is a subset of XML.
HTML, XML, and WML files have a lot in common, so that what web developers have learned over the past 10 years still works today.
The suffix of the WML paging file is *. WML, just like HTML's *. The HTML suffix.
The XML stipulation defines the specification of a specification XML file. Any WML file that violates this rule will be faulted. WML files are usually interpreted using an XML interpreter.
Create a Web page production environment
The WML file itself is a text file, so editing is not a problem, and a handy editor can be used.
Of course, because the current browser is still not able to display WML pages, and we can not always test on the phone (too slow), so need the simulator. Now like Nokia, ERICSSON, Motorola and other mobile phone manufacturers have produced the corresponding products, you just download the line. Of course, in addition to the simulator, but also need graphics production converter (used to make WAP format graphics files), character transcoding (Chinese character <=>unicode), and so on, the site tools and forum pages are described.
WML file structure
A WML page is often called a desktop (DECK), consisting of a set of linked cards (card). When a mobile phone accesses a WML page, all card pages in the page are downloaded from the WAP server to the device. The switch between the card is handled by the computer built in by the telephone, and no more information is needed on the server. Card can contain text, tags, links, input control, Tasks (Task), images, and so on. Card can be linked to each other.
The entity of the document is included in the <wml>...</wml> tag, each card in the document is included in the <card>...</card> tag, and the actual text paragraph is included in the <p> </p> tags.
Simple example:
<?xml version= "1.0"?>
<! DOCTYPE WML public "-//wapforum//dtd WML 1.1//en"
"Http://www.wapforum.org/DTD/wml_1.1.xml" >
<wml>
<card id= "Hello" title= "Hello" >
<p>
Hello world!
</p>
</card>
</wml> |
The results appear as follows:
------HELLO------
Hello world! |
The specific explanations for the various components of deck are explained in other parts of this tutorial.
WML Character Set
WML is a subset of XML that inherits the set of character sets for XML. The default character set for WML documents is UTF-8.
There are two ways to display Chinese. The easiest way to do this is to use encoding in the document header, which is to change the first line to:
| <?xml version= "1.0" encoding= "gb2312"?> |
It is frustrating, however, that some handsets and simulators do not support (in the future), so the 2nd method is more common now: do not change the character set, but use Unicode to represent Chinese characters when writing in Mandarin, such as:
Represent:
WML elements: Tags (tag) and attributes
The main content of WML is text, and because the markup lowers the communication speed with the handheld device, only a small portion of the WML standard is used. Almost all of the tags used for tables and images are excluded.
Like XML, in WML languages, all elements are placed in the symbol "<" and ">" and contain a start flag, a closing flag, a content flag, or a control tag that ends with itself. Just like this:
<tag> content </tag> For example: <p>hello world!</p>
Or
<tag/> such as:<br/> and <go href= "#done"/> |
WML also supports the winning of attributes in a flag. An attribute is an additional information about a flag that is not displayed on the screen, unlike the element's content. Properties are usually specified after the start flag of an element. As the last example above.
Since WML is an application of XML, all WML tags and attributes are case-sensitive (<wml> is completely different from <WML>), and all tags must end correctly. The value of a WML requirement property must be enclosed in double quotes or single quotes. Single quotes can be placed inside a property label or in double quotes. The character can also be used as the value of the property.
WML annotations
XML supports annotation formats such as:
| <!, you can't see--> on your cell phone. |
These comments are not displayed in the browser.
WML does not support nested element annotations.
Link (URL)
WML external references are the same as HTML
HTTP://WWW.ITSALON.NET/INDEX.WML or
Http://www.itsalon.net/index.wml#login |
Internal references, which can be used in this way if Next is a card in the current deck:
The WML element that provides the link functionality has 2:<go> (see tasks ) and <anchor> (see events ).
Cdata
XML supports the concept of CDATA to display text that does not need to be interpreted. The following example uses a CDATA element to display the WML command text in a WML page.
| <! [CDATA [<card name= "bogus" ><p>this is data</p></card>]]> |
The browser window displays the following:
| <card name= "Bogus" ><p>this is data</p></card> |
With the above basis, I believe that we have been able to do a lot of things. Now let's dive in and see how to improve performance and network transfer efficiency. First, you need to introduce the basics of HTTP 1.1 (RFC2616). Of course, if you are already familiar with it, you can skip the first part.
A brief introduction to HTTP 1.1
HTTP 1.1 is a text-based Internet entity information Interaction Mainstream protocol, where the entity can be WAP-compatible browser, such as the user terminal, can be a WAP gateway, such as proxy server, can also be a Java servlet, such as source server programs. The interaction information between them is two broad categories: client-side requests to the server (request) and server-side response to the client (response). A complete interaction consists of a request and a response to it.
All requests and responses are in the standard Internet message format defined in [RFC822], and the framework is as follows:
* Message definition
* No or more message headers
* CRLF (blank line carriage return)
* Optional Message Ontology
Where the message definition specifies the type of message to be sent. Both the request and the response can contain multiple message headers to further or redefine the interaction between the user terminal and the server. CRLF is used only to separate information definitions from message ontologies.
1. Request
In the message definition section you can define the request: Request type URL http/1.1
The request type can be one of the following:
①. Option: Returns the communication options that can be used between the requester and the corresponding person, primarily to detect server processing capabilities;
②. Get: Gets the content of the file or the results of the program execution, as indicated by the URL. The server determines the service content according to the filename suffix, such as whether the URL is static text or a program;
③ Head: In addition to the information ontology that does not return the response, it gets the same information as get. It is generally used to test the validity, accessibility and recent modification of links;
④. POST: Sends messages from the message ontology to a URL or other similar server-side definition behavior. Typically used to submit an HTML form or some data manipulation activity;
⑤. Put: Send messages to a URL in the message ontology, similar to post, but not commonly used;
⑥. Delete: Deletes the resource specified by the URL;
⑦. TRACE: Invokes a remote application layer request message loop. In addition to receiving the original message content, the user terminal that sent the message also gets the route of the message on the Internet.
The most common type of request--and what we care most about when dealing with WAP applications--is get and post. Assuming that a WML document is used, we will send the following GET request to the server when we browse with the up browser:
Get WWW.ITSALON.COM/WAP/INDEX.WML http/1.1
Accept-charset:UTF-8
Accept-language:Ch
Accept:TEXT/VND.WAP.WML, */*, Image/bmp, text/html
user-agent:Up. Browser/3.1-upg1 up. link/3.2
Host:Www.itsalon.net
......
The bold part is the HTTP message header, where we ignore some of the message headers that are not related to us.
Accept-charset:Character set supported by user terminals
Accept-language:The language the user terminal is currently using
Accept:MIME file types acceptable to user terminals
user-agent:Terminal description information provided by the user terminal provider
Host:The domain name to which the request information is sent
2, response
The message definition section of the response is generally like this: the http/1.1 status Code status description defines nearly 40 different status codes in [RFC2616] (divided into 5 groups). The most common of these are 3:
OK
401 Unauthorized
404 Not Found
To continue with the above example, if the URL is valid, the response of the server would be this:
http/1.1 OK
Server:www/5.0
Date:Fri, Oct 12:15:23 GMT
Connection:Keep-alive
content-length:1211
Content_Type:Text/vnd.wap.wml
last-modified:Mon, Oct 18:19:24 GMT
<?xml version= "1.0" >
<!<! DOCTYPE WML public "-//wapforum//dtd WML 1.1//en"
"Http://www.wapforum.org/DTD/wml_1.1.xml" >
......
Other content
......
The response information includes a numeric code and a text description of the response, followed by a set of message headers. After a newline character is the message ontology, where the message ontology is the source code of the WWW.ITSALON.NET/INDEX.WML.
Server:The server that sent the response
Date:Response time of issue
Connection:Instructs the user terminal to remain connected
content-length:The length of the response information, starting with the first "<" character of the deck
Content_Type:MIME type of response
last-modified:Last modified time of deck in response
When a user terminal receives a response, it decodes its state information and message headers, and then decides what action to take on the response. If you receive a OK response, the contents of the message body are usually displayed on the screen. For desktop terminals, it is usually HTML, and for WAP browsers it is WML.
HTTP is a very cumbersome protocol. Even simple requests and responses that do not have any data produce hundreds of-byte messages. WAP addresses this problem through WAP gateways. A very important function of WAP gateway is to convert all HTTP1.1 messages into the message format of the Wireless Task Protocol (Wireless session Protocol, WSP). This format is a compressed binary protocol that is compatible with HTTP1.1. it resolves all requests and response messages and converts them to the most streamlined bit sequences.
Here we have introduced the main contents of HTTP1.1. Of course HTTP1.1 still have a lot of complicated content, but here is not going to say more, if you are interested, you can go to the relevant website to find its information. The authors just want to know that there are more interactive messages between the user terminal and the server than Get and post requests, they have the same request and response headers, and can contain signals to influence the execution and performance of WAP applications. This is the secret to improving the efficiency of WAP operation.
Ii. Caching (Caching)
As defined by [RFC2616], caching is the "local storage area of the response message in the program and the subsystem that controls the storage, retrieval, and deletion of these messages." The cache saves response messages that can be cached in order to reduce future response times and network bandwidth consumption, as well as request messages. "
Because of the bandwidth limitation of WAP channel, we want to minimize the message transmission when we write WAP application. To do this, use the cache as much as possible, often getting the previous message from the cache. Fortunately, most WAP devices now have a certain level of caching, which, by default, tries to maximize the cache. Almost all responses to URLs are cached.
When the WAP user terminal caches a response, it saves almost all information: URL, response text, message header, and other content that can validate the response (see the next section, "Validation and History stacks"). Each cached item can be uniquely identified based on its URL component (domain name, path, protocol, parameters, port, and so on).
There are two types of HTTP headers that let you control the deck cache of WML, and the most important thing for us is the Cache-control message header. It can control all the cached entities directly through the request/response chain. All caching mechanisms must adhere to the definition of these headers. The Cach-control message header is typically used to mask the default caching behavior of a device. They must pass through all proxy servers and gateways without being altered in the message chain.
*
Cache-control:no-cache。 The URL that sets this option cannot be cached, including the user terminal and all other servers between the content server and the user terminal;
*
cache-control:max-age=<second>
。 Defines a URL that guarantees the maximum time in the device cache. When the time is up, the entity clears from the cache;
*
expired:<date> 。 Specifies the last date period on which the URL is stored in the cache. [RFC1123] Defines the format of the date, usually as follows: Expires:sun, October 17:30:47 GMT
When writing a WAP application, you should assume that the user terminal will maximize caching to minimize the movement of information to the content server. Here are some explanations:
1. Permanent Cache URL
The WAP user terminal usually keeps the URL in its cache for as long as possible, and this "as long as possible" definition in the Phone.com browser is about 30 days. However, you may want to keep the cache time of a URL as long as possible, such as your company's logo, so that each time you open the page will be reduced. The following two ways can be easily implemented:
* Specify a very far from the expiration date, such as: Expires:tue, 2002 00:00:00 GMT;
* Specify a large cache time, such as: cache-control:max-age=3153600. This example allows the URL to be cached for one year. The maximum number of integers allowed for a user terminal is 2,147,483,647, so you can keep a URL for more than 68 years. Of course, by that time, your mobile phone was already scrapped.
2, specify the cache time for the URL
Usually the case is for a URL you just need to cache for a while. For example, the stock quotes system, the Web page may need 5 minutes to update, then you only have to deck in the head part of the designated cache-control:max-age=300 on the line. If the user retrieves the page again within 5 minutes, see the page in the cache. If you are in 5 minutes, you will get the most current data on the server.
Another way to control the caching time is to use the expires mentioned earlier, but this method only tells the user that the terminal is refreshed whenever a specified time is passed, regardless of when the page is accessed. If you want to control time, you can only change the time value in expires.
3, prohibit the caching of the URL
For fast-changing content, it is generally desirable to get the latest data every time. So this time to completely prohibit the caching of related Web pages. There are three kinds of methods:
* Set Cache-control:no-cache;
* Set maximum cache time for 0,cache-control:max-age=0;
* Set cache expiration date for a long time past, Expires:mon, 1 1990 00:00:00 GMT.
In fact, the latter two are not the best choice. First of all, this will take up more of the terminal processing time, because when you encounter this deck, the terminal needs to calculate the expiration time. Second, this would take up a bit more bytes and not be clear enough in the expression.
Iii. validation (validation) and history stack (History stack)
The concept of the cache is further presented in HTTP1.1. The purpose of validation is to verify that the cached item is within the validity period. Because of the existence of the historical stack, the verification process on the WAP terminal becomes somewhat complicated.
WAP standards stipulate that all WAP devices should have a history stack of at least 10-item capacity. When the user presses the <go> or other direction to the definition of the directive (forward) link, the URL is pushed (push) into the stack. If pressed by the <prev> A defined back (backward) link in which the URL is bounced (pop).
In general, all the forward links are validated, and the back link is not, because it is already in the cache. But we sometimes hope that when the user presses the Back button, they still get the latest data. If the terminal is always not validated, the user has to find the main menu and re-enter the page.
Fortunately, we use cache-control:must-revalidate to force the user terminal to authenticate the URL when the user presses back. Of course, validation does not mean that the page will be reread immediately, but that it is based on whether or not it expires. If it does not expire, the result of the validation is still to display the page in the cache.
If you need to re-read the page each time back, use Cache-control:must-revalidate, No-cache can be implemented. In addition, replacing No-cache with max-age=300 can refresh a page that has been cached for 300 seconds on the back.
Iv. HTTP headers and META elements
Here, you already know the HTTP message header's role in the WAP page. However, to set these headers in a WML document, you use a META element, which can only appear in a WML document Expires:mon, 00:00:00 GMT
cache-control:max-age=300
Cache-control:no-cache
<meta http-equive= "Expires" content= "Mon, 00:00:00 GMT"/>
<meta http-equive= "Cache-control" content= "max-age=300"/>
<meta http-equive= "Cache-control" content= "No-cache"/>
When gateways scan the elements in WML documents, they are converted to WSP equivalent HTTP headers, and then the user terminal can control the cache accordingly.
