wap builds java applications.htm

jsp+wml的源码,对初接触wap编程的爱好者一点帮助

      <P>Our application has two main goals. First, our mobile sales staff 
      should be able to use it to view their client lists on their WAP devices. 
      Second, if a client wishes to buy goods, then a salesperson should be able 
      to place an order using the device. Furthermore, one of the important 
      goals of any WAP application should be to reduce the number of keypresses 
      that a user must make. Due to the limited nature of a handheld device's 
      user interface, the amount of data that a user is asked to enter should be 
      kept to a minimum. </P>
      <P>Here's a flow diagram showing the structure of our system:</P>
      <P><A name=N100D5><B>Figure 3. Application flow diagram</B></A><BR><IMG 
      height=623 alt="Application flow diagram" 
      src="WAP builds Java applications.files/wapj2ee-fig3.gif" width=431 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P>Users first must log in to access the system; they can then view the 
      client list and details about each client. If they wish to place an order 
      for a particular client, then they are presented with an item list from 
      which they can select a particular item for that client.</P>
      <P>For most of the remainder of this article, we will discuss the servlet 
      and JSP code that drives this application. We'll examine the ways in which 
      JSPs and servlets work together. The discussion of each JavaServer Page is 
      accompanied by a graphic showing that JSP's output on a device screen.</P>
      <P>Listing 1, <A 
      href="listing1.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>Login.jsp</CODE></A> 
      accepts a username and password and uses them as parameters to call the 
      <CODE>LoginServlet</CODE>. For this and all other JSPs, MIME types should 
      be set to be of type <CODE>text/vnd.wap.wml</CODE>. <CODE>Login.jsp</CODE> 
      above also passes a parameter called <CODE>SessionID</CODE> with the 
      request. This must be passed with every request sent to the server. The 
      parameter name <CODE>SessionID</CODE> is a placeholder; refer to your 
      application server documentation to find the correct parameter name for 
      your particular app server. The Java method 
      <CODE>HttpServletResponse.encodeURL(String URL)</CODE> automatically 
      appends the session ID; this has been used within the servlets in our 
      application extensively.</P>
      <P><A name=N1010C><B>Figure 4. PDA displaying login</B></A><BR><IMG 
      height=334 alt="Logging on to the system" 
      src="WAP builds Java applications.files/wapj2ee-fig4.gif" width=310 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P>Validating blank input fields presents a problem. There is an attribute 
      in the <CODE>input</CODE> tag which allows you to make an input field 
      nonblank:</P>
      <TABLE cellSpacing=0 cellPadding=5 width="100%" bgColor=#cccccc 
        border=1><TBODY>
        <TR>
          <TD><PRE><CODE>&lt;input name="name" type="text" <SPAN class=boldcode>emptyok="false"</SPAN>/&gt;</CODE></PRE></TD></TR></TBODY></TABLE>
      <P>A mobile phone user must go to a separate input dialog screen to enter 
      data. Our problem arises because the user may choose to go directly to the 
      next deck or card rather than go to the input dialog screen and enter data 
      in the field. A user confronted with the screen in Figure 4 may omit the 
      password and tap Next.</P>
      <P>A developer could prevent this from happening by validating using 
      WMLScript, using the <CODE>onclick</CODE> event. However, the variable 
      representing the input field value that you pass to the WMLScript function 
      is not initialized until you enter a value in the input box. Hence, with 
      no password entered, the function is passed an uninitialized variable and 
      a script error results. The solution to this problem is to validate all 
      input fields on the server side.</P>
      <P>Listing 2, <A 
      href="listing2.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>LoginServlet</CODE></A> 
      is the solution to our problem: it authenticates the salesperson and logs 
      him into the system. It also creates a session for the salesperson on the 
      server side. Comments in the code block above indicate the points at which 
      these actions are performed. Upon a successful login, the device displays 
      the main menu shown in Listing 3 (<A 
      href="listing3.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>MainMenu.jsp</CODE></A>). 
      </P>
      <P>This file displays two links on the device screen, as shown in Figure 
      5. The second link ends the current session; the first leads to the 
      current client list. In the current version of the program flow, the 
      salesperson must select a client from the list before beginning any sales 
      transaction; the list of sales items can only be reached from subsequent 
      screens (the details are to follow). Other program flows are possible: for 
      example, a link could be added to the main menu that sends the user 
      directly to the item list. However, you should not to provide too many 
      links on any one menu, as the small screens of WAP-enabled devices can 
      easily become cluttered.</P>
      <P><A name=N10147><B>Figure 5. PDA displaying main menu</B></A><BR><IMG 
      height=334 alt=Login.jsp 
      src="WAP builds Java applications.files/wapj2ee-fig5.gif" width=310 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P>Tapping on View Clients on the menu screen in Figure 5 calls the <A 
      href="listing4.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ClientViewServlet</CODE></A> 
      in Listing 4, which extracts the list of clients that the salesperson is 
      to visit. Comments in the code demonstrate how the servlet finds this 
      information on the client side. The servlet then places this list in the 
      session object and calls <CODE>ClientList.jsp</CODE>. (The session object 
      referred to here and in the next section refers to the 
      <CODE>HttpSession</CODE> class provided as part of the Java servlet 
      package.)</P>
      <P>Listing 5, <A 
      href="listing5.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ClientList.jsp</CODE></A> 
      extracts the list of clients placed in the session by the 
      <CODE>ClientViewServlet</CODE>; it displays the names of the clients, but 
      not the complete details (see Figure 6). Upon selecting one of the 
      clients, the salesperson is directed to 
<CODE>ClientDetails.jsp</CODE>.</P>
      <P><A name=N10179><B>Figure 6. PDA displaying client list</B></A><BR><IMG 
      height=334 alt=Login.jsp 
      src="WAP builds Java applications.files/wapj2ee-fig6.gif" width=310 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P>Note that the task of displaying of the client list into three separate 
      components -- <CODE>ClientViewServlet</CODE>, <CODE>ClientList.jsp</CODE>, 
      and <CODE>ClientDetails.jsp</CODE>. What are the reasons for this 
      design?</P>
      <OL xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <LI>Most authorities on J2EE architecture recommend that JSPs should not 
        directly access EJBs; intermediate components like servlets should 
        interact with the EJBs instead. The <CODE>ClientViewServlet</CODE> 
        accesses the EJB and obtains the list of clients. 
        <LI>The application could have been designed so that all client details 
        would be contained in a single WML document. In this architecture, the 
        client list would be contained in one card of a WML deck and the details 
        for individual clients would be contained in separate cards in the same 
        deck. But this single WML document might contain too much data for a 
        low-bandwidth WAP device to download at once. If the number of clients 
        is high, the amount of data generated could easily exceed the maximum 
        deck size permitted for a WML deck. (The maximum deck size varies from 
        device to device; for the Nokia 7110 the maximum compiled deck size is 
        1.3 KB). Hence we used two JSPs: <CODE>ClientList.jsp</CODE>, for 
        displaying the list of clients, and <CODE>ClientDetails.jsp</CODE>, for 
        displaying the details of individual clients. </LI></OL>
      <P>Listing 6, <A 
      href="listing6.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ClientDetails.jsp</CODE></A> 
      accepts as a parameter an index into the array of clients, which is 
      present in the session. It then extracts the details of the selected 
      client and displays them. If the salesperson wishes to place an order for 
      this client, he taps on the Items button. This invokes Listing 7, <A 
      href="listing7.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ItemListServlet</CODE></A> 
      and displays the items available for order.</P>
      <P><A name=N101BC><B>Figure 7. PDA displaying client 
      detail</B></A><BR><IMG height=334 alt="PDA displaying client detail" 
      src="WAP builds Java applications.files/wapj2ee-fig7.gif" width=310 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P>Listing 7, <A 
      href="listing7.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ItemListServlet</CODE></A> 
      extracts the list of items that the salesperson can sell and places that 
      list in the session. It then calls Listing 8, <A 
      href="listing8.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ItemList.jsp</CODE></A>.</P>
      <P>Listing 8, <A 
      href="listing8.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>ItemList.jsp</CODE></A> 
      extracts the list of items from the session and displays the item names. 
      The salesperson can select an item to order and tap the Order button to 
      invoke <CODE>PlaceOrder.jsp</CODE>. The index of the selected item in the 
      array is sent as a parameter to Listing 9, <A 
      href="listing9.htm" 
      target=_new xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><CODE>PlaceOrder.jsp</CODE></A>.</P>
      <P><A name=N101F0><B>Figure 8. PDA displaying item list</B></A><BR><IMG 
      height=334 alt="PDA displaying item list" 
      src="WAP builds Java applications.files/wapj2ee-fig8.gif" width=310 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P><CODE>PlaceOrderServlet</CODE> obtains the salesperson, customer, and 
      item IDs from the session. A new order is then placed by the creation of a 
      new Order Entity EJB. The successful placement of an order displays an 
      order ID and the time the order was placed.</P>
      <P>In this version of the application, the salesperson's only option after 
      completing the transaction is to return to the main menu (see Figure 9). 
      You could alter the code to send the user back to the client or item lists 
      as well.</P>
      <P><A name=N10207><B>Figure 9. PDA displaying transaction complete 
      message</B></A><BR><IMG height=334 
      alt="PDA displaying transaction complete message" 
      src="WAP builds Java applications.files/wapj2ee-fig9.gif" width=310 
      xmlns:fo="http://www.w3.org/1999/XSL/Format" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"></P>
      <P>If you've been paying attention, you noticed that the salesperson only 
      enters data twice: when logging on and when entering the number of items 
      to buy for the customer.</P>
      <P><A name=N10217><SPAN class=atitle2>About the code</SPAN></A><BR>The 
      attached files include all the JSP and servlet code included in this 
      article as well as the necessary EJB code. The jar file of the EJBs is 
      also included, along with the deployment descriptors. The screen shots are 
      from Nokia's WAP Simulator 2.0.</P>
      <P><A name=N10222><SPAN class=atitle2>Conclusion</SPAN></A><BR>As 
      mentioned previously, a WAP application provides a very nice value-added 
      service. A standalone WAP application is not a feasible idea. However, 
      such an application can be easily incorporated into any existing Web 
      application architecture without much monetary or labor investment. The 
      only new hardware you'll need is a machine and software for the WAP 
      gateway; if you are using your ISP's gateway, even this cost is 
      eliminated. </P>