JSP and Page Templates

This chapter discusses:

The midtier framework.
Scope of the servlet.
Using JSP processing.
Writing JSP.
Using generated Java and class files.

The Midtier Framework

The source code for the midtier applications is put into a set of text files that resemble HTML pages. Each file, or page, contains the HTML code for the generic style of the web server’s HTTP response to the types of HTTP requests from the user. These generic response pages are called page templates.

The emergence of JavaServer Pages (JSP) technology enables web page designers to intersperse Java source code with the HTML code to script server-side servlets that will compile and execute on the midtier host at run time. JSP includes the following languages:

Java (scriptlets)
HTML and JavaScript
JSP tags

Note. JSP does not include, but does allow, client-side JavaScript, which is treated the same as HTML.

The web server passes incoming user requests to an application server specified by the port number portion of the URL. The application server converts the JSP source into pure Java source (for a servlet implementation). Then the application server runs the newly created servlet in its servlet engine. The output of the servlet is a stream of HTML text that the application passes to the web server to return to the user’s browser.

The following diagram shows the flow of communication between the midtier and the user:

Each JSP page processes a response to a user request

PeopleSoft Advanced Configurator’s framework employs the WebLogic application server in its environment. WebLogic application servers by default employ the port number 7777, but may be set to listen to the standard port 80.

Note. An external web server can be configured to proxy requests for JSP pages to the application server using port 7777.

Users would load the JSP pages using the web server’s host name (and port number if not port 80), as shown in the following URL:

http://WebServerHostName:7777/sample/myPC-page1.jsp

Whenever the user loads a JSP page in a browser, the WebLogic application server converts the JSP into a servlet JAVA file and a corresponding servlet CLASS file that implements the servlet interface. These files live securely on the machine hosting the WebLogic server, not in the browser. The WebLogic server then runs the servlet, which generates HTML that is served back to the browser. During a Configurator session, the user is linking to and loading JSP pages, yet only sees HTML output in the browser.

Note. You can compare the JSP source (on the midtier server) with the generated HTML (in the user’s browser: use the View/Page Source menus).

The following diagram shows the transition from JSP source code to an executing servlet:

JSP executes on the midtier and displays HTML in the browser

Note. This compilation only occurs the first time that the JSP page is requested; however, if that JSP source file is modified, then WebLogic recompiles it.

Scope of the Servlet

Each page template defines a separate servlet that executes the complete Configurator response to an HTTP user request. Each servlet binary remains cached to rapidly respond to a particular request from any subsequent user or any subsequent session.

The Configurator’s midtier servlets are like any other servlets—their scope is not limited to the source in a single JSP page or file. The Java code can call out to objects and methods in external CLASS or JAR files anywhere in the servlet CLASSPATH.

Best practices for JSP design use a scripting philosophy, keeping the page size small and complexity per page at a minimum. This enables rapid code development/deployment and easier maintenance. However, JSP-based applications need not be small or simple. JSP uses special directive tags to call out to JavaBeans or other components where much of the application logic can be delegated (and be transparent to the JSP source).

Using JSP Processing

A JSP source file is processed in two stages—translation time and request processing time. At translation time, which occurs when a user first loads a JSP page, the JSP source file is compiled to a Java class, usually a Java servlet. The HTML tags and as many JSP tags as possible are processed at this stage, before the user makes a request.

Request processing time occurs when the user clicks in the JSP page to make a request. The request is sent from the client to the server by way of the request object. The JSP engine then executes the compiled JSP file, or servlet, using the request values the user submitted.

When you use scripting elements in a JSP file, you should know when they are evaluated. Declarations are processed at translation time and are available to other declarations, expressions, and scriptlets in the compiled JSP file. Both expressions and scriptlets are also evaluated at translation time. The value of each expression is converted to a string and inserted in place in the compiled JSP file. Scriptlets, however, are evaluated at request processing time, using the values of any declarations and expressions that are made available to them.

The JSP page finally responds to the request as the source reads sequentially; that means that each block of Java code—and its resulting display—fires in the normal sequence of the HTML page, just as you’ve written it.

Writing JSP

JSP programming is beyond the scope of this document; however, you can access a very useful online tutorial for JSP at the following URL:

http://e-docs.bea.com/wls/docs81/jsp/index.html

You can comfortably read JSP code simply by knowing how the Java code can be embedded within the HTML, and how the HTML code can be embedded within the Java.

The scriptlet syntax <% ... %> can handle declarations, expressions, or any other type of code fragment valid in the page scripting language, e.g., Java.
The include syntax <%@ include file="anotherJspFile" %> includes a specified external JSP page.
JSP uses special tags to embed Java code within the HTML: The expression syntax <%= ... %> defines a scripting language expression and casts the result as a string.
The declaration syntax <%! ... %> declares variables or methods.

When you mingle scripting elements with HTML and JSP tags, you must always end a (JSP) scripting element before you start using (HTML) tags and then reopen the scripting element afterwards, as shown in the following JSP code:

<%   	
   if   (condition) {	
%> 	<!-- closing the scriptlet before the HTML tags start -->
 	<!-- HTML text goes here outside the scripting tags...-->
<%   } 	
   else { 	
%> 	<!-- closing the scriptlet before the HTML tags start -->
 	<!-- HTML text goes here outside the scripting tags...-->
<%   }           %>	<!-- reopening a scriptlet to close the else {} block -->

HTML text can be embedded within print statements in the Java code portions, for example
```
out.println(" collection:" +
currCollectionProperty.getName()+" ");
```

You can have multiple blocks of Java code throughout a JSP page. You can switch between HTML and Java code anywhere, even within Java constructs and blocks. Notice in the loop shown here that declares a Java loop, switches to HTML, then back to Java to close the loop. The HTML is output multiple times as the loop iterates.

The following JSP code generates the typical “Hello World” HTML web page:

<html>
<head><title>Hello World in JSP</title></head>
<body>
<h1> Hello World Test </h1>
<p><i> This is HTML. The following is Java! </i><p>
	<% 
			for (int i = 1; i<=5; i++)
				out.print("This is a Java loop! " + i + "Hello World<p>");
	%> 
</body>
</html>

You can use the implicit object out to print directly to the servlet output stream from your Java code. Therefore, the servlet can output HTML text directly, as illustrated in the following line of JSP code:

out.print("This is a Java loop! <i>" + i + "</i> <p>");

Using Generated Java and Class Files

When the application server first compiles one of your JSP pages within your client application directory, the application server also creates the following folder and files, all named with a prepending underscore “_” character:

A corresponding application directory by the same application name.
A JAVA source file.
A Java CLASS file.

WebLogic stores this new directory structure in:

\bea\weblogic81\config\CalicoDomain\myserver\.wlnotdelete\extract\myserver_CalicoDomain_CalicoApp\jsp_servlet

The application server also creates a corresponding JAVA source file and Java CLASS file with an underscore prefix for the Configurator JSP processor page.

For example, a Web client application contains these JSP pages:

C:\WirelessPlan\pages\myappdirectory\MyPage1.jsp C:\WirelessPlan\pages\myappdirectory\CalicoProcessForm.jsp C:\WirelessPlan\pages\myappdirectory\alicoUI.properties

The application server creates the following directory and files for saving the JAVA and CLASS files:

\bea\weblogic81\config\CalicoDomain\myserver\.wlnotdelete\extract\ myserver_CalicoDomain_CalicoApp\jsp_servlet\_myapp directory\_myPage1.java _myPage1.class _CalicoProcessForm.java _CalicoProcessForm.class

The application server generates only a Java source file and compiles it each time the Web client first requests a newly installed, or modified, JSP page.