Getting Started
|
 |
 |
|
|
 |
 |
You can use this 10-step tutorial guide to learn how to:
This chapter illustrates how you can use Liquid Data to create a query that treats multiple disparate data sources as a single data source. It assumes a large Internet company that has grown through mergers or acquisitions and, as a consequence, finds that its real-time order data must be accessed from two very separate data sources: Wireless order data from an RDBMS system; BroadBand order data via an XML document.
As you work through this Order Report example, keep in mind that each action you take generates source code, in some cases significant amounts. When you are done, you will find that your application contains nearly 500 lines of Java code, 97% of which was automatically generated. (For details see Generated Files and Code on page 54.)
Getting Started contains numerous illustrations in the form of screen captures. The goal is to enable you to create a query accessing multiple data sources and use that query when building and running a simple but complete web application — in less than 60 minutes!
The 10 steps in building up the Order Report web application are:
Examples used in this chapter assume that the Liquid Data 8.1 sample domain is located at:
<WL_HOME>/samples/domains/liquiddata/
where WL_HOME is the root location of the WebLogic Server 8.1.
You can find many other examples and samples in Liquid Data by Example, including the Avitek Customer Self-Service Sample Application which also combines the back-end data retrieval capabilities of Liquid Data with WebLogic Workshop to create a more fully-functional customer self-service web application.
The Liquid Data Samples server is simply a WebLogic Server 8.1 that contains Liquid Data samples, including a Liquid Data repository. It can be started from Windows or UNIX.
To start the Liquid Data samples server under Windows choose the following menu option:
Start—> Programs—> BEA WebLogic Platform 8.1—>—
BEA Liquid Data for WebLogic 8.1 SP2>Liquid DataSamples—> Samples Server
To start the Liquid Data samples server under UNIX run the startWeblogic.sh shell command in the following domain:
<WL_HOME>/samples/domains/liquiddata/startWeblogic.sh
When the Samples server is ready you will see Server started in RUNNING mode.
Note: For more information on setting up and starting the Samples server, see Post-Installation Tasks in the Liquid Data Installation Guide. For more information on starting Liquid Data servers in the various preconfigured domains, see Starting and Stopping the Server in the Liquid Data Administration Guide.
The Liquid Data repository is managed and configured through the Liquid Data node of the WebLogic Administration Console. It is here that data sources are defined, security policies established, and so forth.
The WebLogic Administration Console can be accessed from Windows or UNIX.
To start the WebLogic Administration Console under Windows choose the following menu option:
Start—> Programs—> BEA WebLogic Platform 8.1—> BEA Liquid Data for WebLogic 8.1 SP2—>Liquid DataSamples—> Admin Console
To start the WebLogic Administration Console for the Liquid Data Samples server running on your local machine, enter the following URL in a web browser:
http://localhost:7001/console
Log in to the console by providing the following default username and password for the Samples server:
Figure 1 Entering WebLogic Administration Console Login Information
After you log in, the Console home page is displayed. Note that Liquid Data is the bottom element in the left pane (Figure 2).
Figure 2 WebLogic Administration Console
Note: For more information on using the Liquid Data node of the WebLogic Administration Console, see the Liquid Data Administration Guide.
This section describes how to use the WebLogic Administration Console to configure the two sample data sources used in the tutorial customer order report:
A first step in making a data source available to Liquid Data is to register your data source with the Administration Console. To add a description of your RDBMS data source to the Liquid Data Server registry follow these steps:
Configure a New Relational Database Data Source Description link to display the Configure tab (Figure 4).Figure 3 Creating a New Relational Database Data Source
Figure 4 A Relational Database Data Source Defined
To create a description of your XML data source, follow these steps:
Configure a New XML Data Source Description link to access the Configure dialog box (Figure 5).Figure 5 Defining a XML Data Source Definition
Next, you are ready to start the Windows-based Data View Builder. This is where you will create and test your query. You can start the Data View Builder two ways:
Start—> Programs—> BEA WebLogic Platform 8.1—> BEA Liquid Data for WebLogic 8.1 SP2—> Data View Builder
If you are not already connected to the Liquid Data Samples server, enter the following address in the Server URL field in the Welcome... dialog box (Figure 6).
t3://localhost:7001
No username or password is needed; leave those fields blank.
Figure 6 Data View Builder Login Dialog
The Data View Builder allows you to build queries (and data views) through graphical representations of your data and any query conditions.
You first define your query by dragging and dropping (mapping) elements from source to target schemas. Constants, parameters, and functions are available to fully express a query statement.
The customer order report query you are building assumes that you have customer orders stored in two data sources (Wireless in a relational database and BroadBand in an XML file). The query will return the order information for any particular customer.
To construct the example customer order report query, you need to:
Constructing the "Order Query" Demo... If you are looking at this documentation online, you can click the Demo button to view an animated demonstration of how to build up the conditions and create the mappings that are similar to this example. With minor variations, the Order Query demo previews Steps 1-7 of this chapter.
To start building a query, first select the schemas for the data sources you need.
Note: Move data sources around on the workspace as needed.
A target schema represents a structure of your query results. (For additional information on target schemas see "Understanding Target Schemas" in the Schemas and Namespaces in Liquid Data chapter of Building Queries and Data Views.)
For this example, use customerOrderReport.xsd as your target schema.
Figure 8 Selecting a Target Schema from the Liquid Data Repository
Note: Schemas are located in the following Liquid Data repository directory:
<WL_HOME>/samples/domains/liquiddata/ldrepository/schemas
Figure 9 Data View Builder Showing Source and Target Schemas
At this point, your work area contains two data source schemas and a target schema.
The Data View Builder generates queries based on your mapping of source elements to your target schema.
The CustomerOrderReport target schema includes a CUSTOMER_ORDER node for both Wireless and BroadBand. Map CUSTOMER_ORDER elements from each data source to the corresponding CUSTOMER_ORDER elements in the target schema as follows:
Figure 10 Mapping Elements in Wireless : CUSTOMER_ORDER to the Target Schema
Figure 11 Mapping Elements in Broadband : CUSTOMER_ORDER to the Target Schema
In both cases, you mapped the sub-elements: ORDER_DATE, ORDER_ID, CUSTOMER_ID, SHIP_METHOD, and TOTAL_ORDER_AMOUNT to corresponding elements in your target schema.
Note: As you map elements from source to target, descriptions appear in the lower part of the workspace (Figure 13). If you need to delete an incorrect mapping, click in the Mapping ID field to highlight the row you wish to delete. Then click the Trash icon on your lower left.
Use the Wireless data source schema to populate the CUSTOMER element in the target schema.
Figure 12 Mapping Elements in Wireless : CUSTOMER to the Target Schema
At this point, you have completed the source-to-target mappings and your target schema is ready.
The 16 source-to-target mappings you created appear on the Mappings tab (Figure 13).
Figure 13 Complete List of Source-to-Target Mappings
The purpose of the query is to retrieve BroadBand and Wireless transactions for a specified customer. The following sections describe how to define conditions for the project you are building:
In the Wireless data source drag and drop the element CUSTOMER : CUSTOMER_ID to CUSTOMER_ORDER : CUSTOMER_ID to create a join between CUSTOMER and CUSTOMER_ORDER:
The syntax of this join appears on the first row of the Conditions tab.
Note: Whenever you create a query condition, the Conditions tab is automatically displayed in the lower part of the workspace (Figure 14).
Drag and drop the Wireless element CUSTOMER : CUSTOMER_ID onto the BroadBand data source element CUSTOMER_ORDER : CUSTOMER_ID:
Note: If you run the query at this point, your results retrieve information on all customers in your customer database.
Although you could use a constant to "hard-code" your query for a particular customer, creating a query parameter is a more flexible approach. Using a query parameter, you can retrieve information on any customer in your data set.
myCustomer as the name and select string from the Type pulldown menu (see Figure 14).Figure 15 Creating a New Parameter of Type String
myCustomer query parameter to the CUSTOMER : CUSTOMER_ID element of MyWirelessLD-DS database schema:
Figure 16 Mapping a Parameter to a Source Schema Element
You have now set up all the source conditions needed for your query.
Figure 17 Complete Set of Conditions
Although not necessary in all cases, it is good practice to set a namespace for your target schema. See "Understanding XML Namespaces" in the Overview and Key Concepts chapter of Building Queries and Data Views.
To set a target namespace for the customerOrderReport target schema follow these steps:
Figure 18 Specifying a Target Namespace
Figure 19 Target Schema with New Namespace
At this point you have assembled all the query elements. Specifically you have mapped data source elements to your target schema, you have created the necessary joins, and you have specified a query parameter functioning similarly to a SQL WHERE clause.
When you enter Test mode, your query is automatically generated.
Click the Test tab at the top of the workspace (Figure 20). After a few moments your query will automatically appear.
Figure 20 Supplying a Query Parameter
The automatically generated XQuery is shown in Listing 5.
Listing 5 Generated customerOrderReport Query
namespace custorder = "urn:schemas-bea-com:ld-custorder"
<custorder:CustomerOrderReport>
{
for $MyWireless_LD_DS.CUSTOMER_1 in document("MyWireless-LD-DS")/db/CUSTOMER
where ($#myCustomer of type xs:string eq $MyWireless_LD_DS.CUSTOMER_1/CUSTOMER_ID)
return
<customerOrder>
<CUSTOMER>
<FIRST_NAME>{ xf:data($MyWireless_LD_DS.CUSTOMER_1/FIRST_NAME) }</FIRST_NAME>
<LAST_NAME>{ xf:data($MyWireless_LD_DS.CUSTOMER_1/LAST_NAME) }</LAST_NAME>
<CUSTOMER_ID>{ xf:data($MyWireless_LD_DS.CUSTOMER_1/CUSTOMER_ID) }</CUSTOMER_ID>
<STATE>{ xf:data($MyWireless_LD_DS.CUSTOMER_1/STATE) }</STATE>
<EMAIL_ADDRESS>{ xf:data($MyWireless_LD_DS.CUSTOMER_1/EMAIL_ADDRESS) }</EMAIL_ADDRESS>
<TELEPHONE_NUMBER>{ xf:data($MyWireless_LD_DS.CUSTOMER_1/TELEPHONE_NUMBER) }</TELEPHONE_NUMBER>
</CUSTOMER>
<wireless_orders>
{
for $MyWireless_LD_DS.CUSTOMER_ORDER_2 in document("MyWireless-LD-DS")/db/CUSTOMER_ORDER
where ($MyWireless_LD_DS.CUSTOMER_1/CUSTOMER_ID eq $MyWireless_LD_DS.CUSTOMER_ORDER_2/CUSTOMER_ID)
return
<CUSTOMER_ORDER>
<ORDER_DATE>{ xf:data($MyWireless_LD_DS.CUSTOMER_ORDER_2/ORDER_DATE) }</ORDER_DATE>
<ORDER_ID>{ xf:data($MyWireless_LD_DS.CUSTOMER_ORDER_2/ORDER_ID) }</ORDER_ID>
<CUSTOMER_ID>{ xf:data($MyWireless_LD_DS.CUSTOMER_ORDER_2/CUSTOMER_ID) }</CUSTOMER_ID>
<SHIP_METHOD>{ xf:data($MyWireless_LD_DS.CUSTOMER_ORDER_2/SHIP_METHOD) }</SHIP_METHOD>
<TOTAL_ORDER_AMOUNT>{ xf:data($MyWireless_LD_DS.CUSTOMER_ORDER_2/TOTAL_ORDER_AMOUNT) }</TOTAL_ORDER_AMOUNT>
</CUSTOMER_ORDER>
}
</wireless_orders>
<broadband_orders>
{
for $MyBroadBand_LD_DS.CUSTOMER_ORDER_3 in document("MyBroadBand-LD-DS")/db/CUSTOMER_ORDER
where ($MyWireless_LD_DS.CUSTOMER_1/CUSTOMER_ID eq $MyBroadBand_LD_DS.CUSTOMER_ORDER_3/CUSTOMER_ID)
return
<CUSTOMER_ORDER>
<ORDER_DATE>{ xf:data($MyBroadBand_LD_DS.CUSTOMER_ORDER_3/ORDER_DATE) }</ORDER_DATE>
<ORDER_ID>{ xf:data($MyBroadBand_LD_DS.CUSTOMER_ORDER_3/ORDER_ID) }</ORDER_ID>
<CUSTOMER_ID>{ xf:data($MyBroadBand_LD_DS.CUSTOMER_ORDER_3/CUSTOMER_ID) }</CUSTOMER_ID>
<SHIP_METHOD>{ xf:data($MyBroadBand_LD_DS.CUSTOMER_ORDER_3/SHIP_METHOD) }</SHIP_METHOD>
<TOTAL_ORDER_AMOUNT>{ xf:data($MyBroadBand_LD_DS.CUSTOMER_ORDER_3/TOTAL_ORDER_AMOUNT) }</TOTAL_ORDER_AMOUNT>
</CUSTOMER_ORDER>
}
</broadband_orders>
</customerOrder>
}
</custorder:CustomerOrderReport>
Once generated, your query is ready to be tested. However, you need to supply the customer ID parameter you set up in Create a Query Parameter on page 19.
Click in the Value field next to myCustomer and directly enter CUSTOMER_1, as (see Figure 20).
Note: Query parameters are case sensitive.
When you are ready to run the query, click the Run query button on the toolbar in the upper left (Figure 21).
The Liquid Data server processes the query and returns results. Right-click —> Expand on the top line of the generated results (customerOrder) to view your data in an outline-like arrangement.
Figure 22 Test Mode Displaying Query and Result in Tree Format
If you click the View as XML checkbox in the lower part of the Test view area of the Data View Builder, query results are displayed in XML (see Listing 6).
<prefix1:CustomerOrderReport xmlns:prefix1="urn:schemas-bea-com:ld-custorder">
<customerOrder>
<CUSTOMER>
<FIRST_NAME>JOHN_1</FIRST_NAME>
<LAST_NAME>KAY_1</LAST_NAME>
<CUSTOMER_ID>CUSTOMER_1</CUSTOMER_ID>
<STATE>TX</STATE>
<EMAIL_ADDRESS>abc@abc.com</EMAIL_ADDRESS>
<TELEPHONE_NUMBER>4081231234</TELEPHONE_NUMBER>
</CUSTOMER>
<wireless_orders>
<CUSTOMER_ORDER>
<ORDER_DATE>2002-03-06</ORDER_DATE>
<ORDER_ID>ORDER_ID_1_0</ORDER_ID>
<CUSTOMER_ID>CUSTOMER_1</CUSTOMER_ID>
<SHIP_METHOD>AIR</SHIP_METHOD>
<TOTAL_ORDER_AMOUNT>1000</TOTAL_ORDER_AMOUNT>
</CUSTOMER_ORDER>
<CUSTOMER_ORDER>
<ORDER_DATE>2002-03-06</ORDER_DATE>
<ORDER_ID>ORDER_ID_1_1</ORDER_ID>
<CUSTOMER_ID>CUSTOMER_1</CUSTOMER_ID>
<SHIP_METHOD>AIR</SHIP_METHOD>
<TOTAL_ORDER_AMOUNT>2000</TOTAL_ORDER_AMOUNT>
</CUSTOMER_ORDER>
</wireless_orders>
<broadband_orders>
<CUSTOMER_ORDER>
<ORDER_DATE>2002-04-09</ORDER_DATE>
<ORDER_ID>ORDER_ID_1_0</ORDER_ID>
<CUSTOMER_ID>CUSTOMER_1</CUSTOMER_ID>
<SHIP_METHOD>AIR</SHIP_METHOD>
<TOTAL_ORDER_AMOUNT>1000.00</TOTAL_ORDER_AMOUNT>
</CUSTOMER_ORDER>
<CUSTOMER_ORDER>
<ORDER_DATE>2002-04-09</ORDER_DATE>
<ORDER_ID>ORDER_ID_1_1</ORDER_ID>
<CUSTOMER_ID>CUSTOMER_1</CUSTOMER_ID>
<SHIP_METHOD>AIR</SHIP_METHOD>
<TOTAL_ORDER_AMOUNT>1500.00</TOTAL_ORDER_AMOUNT>
</CUSTOMER_ORDER>
</broadband_orders>
</customerOrder>
</prefix1:CustomerOrderReport>
You have successfully built and run a query using Liquid Data.
Note: To switch back to Data View Builder Design mode, click the Design View tab on the toolbar.
Now that you have successfully built and run a query, you can save your Data View Builder project. The next time you need to run or modify your query or Data View, you can simply reopen the project.
See "Working With Projects" in the Starting the Builder and Touring the GUI chapter of Building Queries and Data Views.
To use of the results of your query in an application such as WebLogic Workshop, you first need to associate a saved query with a saved target schema. This is known as deploying a query and provides the metadata necessary to create an XMLBean that provides data access services in Workshop. (See "Deploying a Query" in the Testing Queries chapter of Building Queries and Data Views.)
Follow these steps to deploy your query:
Figure 23 Deploy Query Save Target Schema Dialog Box
custOrdRpt.xsd Figure 24 Deploy Query Save Target Schema Dialog Box
Figure 25 Deploy Query Save Current Query Dialog Box
Figure 26 Creating a Stored Query
Figure 27 Deploying custOrdRpt Query with custOrdRpt Schema
Once you have deployed a query, you can quickly make it available to WebLogic Workshop. (For details see "Using WebLogic Workshop Controls to Develop Liquid Data Applications" in the Application Developer's Guide.)
In the following two sections you will undertake:
A Liquid Data control provides access from WebLogic Workshop to queries that have been deployed to a Liquid Data server.
custOrdRpt as the application name. Notice that the selected application type is Default Application.Figure 28 Creating a New WebLogic Workshop Application
When you create a default application, a project of type Web Project is automatically built using the name of the application plus Web. In this case the project is custOrdRptWeb.
Figure 29 Creating a Web Project Within the New Application
Figure 30 Creating a New Java Control
Enter custOrdRpt as the filename for the control (Figure 31). The Liquid Data control enables you to turn Liquid Data queries into XML Beans which can be used by a WebLogic Workshop application.
Figure 31 Selecting and Naming a Liquid Data Control
Figure 32 Creating a New Java Control Dialog
Figure 33 Adding a Deployed Query to a Liquid Data Control
Figure 34 Design View of Liquid Data Control
The final section takes you through the steps required to build a web application that display query results in automatically-generated java server pages (JSP).
Once a Liquid Data Control is available, its query elements can be built into JSP pages through creation of a WebLogic Workshop application.
WebLogic Workshop applications are driven by a single page flow file, identified by its .jpf extension. When you generate a page flow, WebLogic Workshop creates the page flow file and several other files. (For details see "Generating a Page Flow From a Control" in the chapter Using Workshop Controls to Develop Liquid Data Applications in the Application Developer's Guide.)
Perform the following steps to generate a page file (custOrdRpt.jpf) from a Liquid Data java control.
Figure 35 Generating a Page Flow Document From a Liquid Data Java Control
custOrdReport, there only one method. Click the checkbox to the left of the method (Figure 36). Figure 36 Identifying the Liquid Data Methods for the Page Flow
The application Flow View graphically depicts the relationship between the various pages of your application.
success link that connects the begin element to index.jsp by selecting the link (click on it) and then choose Right-click —> Delete (Figure 38). The change is needed because index.jsp will not be the application's start-up page.Figure 38 Removing a Page Flow Link
begin to custOrdRpt.jsp; click adjacent to begin. Then, holding your mouse button down, draw a link to custOrdRpt.jsp (Figure 39). It will automatically be labeled success. Based on the XMLBean that was created from the custOrdRpt deployed query, a customer ID parameter is required by the web application. In WebLogic Workshop the new initial application page (custOrdRpt.jsp) requests a Customer ID. (See Create a Query Parameter on page 19.)
Figure 39 Creating a New Page Flow Link
You can now test your application for data access.
custOrdRptController page appears. Enter a query parameter such as CUSTOMER_3 (Figure 40).Note: Case matters; customer_3 will not succeed.
Figure 40 Supplying a Query Parameter From the New Application
While the application's Java Page Flow (JPF) file is automatically generated, a few lines of Java code are needed to add XMLBean variables to your page flow. (For details see the topics "Adding XMLBean Variables to the Page Flow" and "To Initialize the Variable in the Page Flow" in the chapter Using Workshop Controls to Develop Liquid Data Applications in the Application Developer's Guide.)
Follow these steps to copy several lines of Java code into the correct section of custOrdRptController.jpf:
public schemasBeaComLdCustorder.CustomerOrderReportDocument.CustomerOrderReport.CustomerOrder.BroadbandOrders.CUSTOMERORDER[] BroadBand;
public schemasBeaComLdCustorder.CustomerOrderReportDocument.CustomerOrderReport.CustomerOrder.WirelessOrders.CUSTOMERORDER[] Wireless;
public schemasBeaComLdCustorder.CustomerOrderReportDocument.CustomerOrderReport.CustomerOrder Customers;
These instructions create three variables. Two represent the CUSTOMERORDER[] arrays for BroadBandOrders and WirelessOrders data sources, respectively. The third, Customers, represents data associated with a particular customer.
custOrdRpt form. An easy way to do this is to search. From the WebLogic Workshop menu select Edit —> Find (or Control-F). Search for a section of code beginning with the string:Forward custOrdRpt
Wireless = var.getCustomerOrderReport().getCustomerOrderArray(0).getWirelessOrders().getCUSTOMERORDERArray() ;
BroadBand = var.getCustomerOrderReport().getCustomerOrderArray(0).getBroadbandOrders().getCUSTOMERORDERArray() ;
Customers = var.getCustomerOrderReport().getCustomerOrderArray(0);
These instructions make the three public variables available to the application. The relevant code is shown in Figure 7 (newly entered lines are in boldface).
Listing 7 CustOrdRpt Page Flow File (custOrdRptController.jpf).
package custOrdRpt;
import com.bea.wlw.netui.pageflow.FormData;
import com.bea.wlw.netui.pageflow.Forward;
import com.bea.wlw.netui.pageflow.PageFlowController;
import custOrdRpt.custOrdRpt;
...
public class custOrdRptController extends PageFlowController
{
/**
* This is the control used to generate this pageflow
* @common:control
*/
private custOrdRpt myControl;
public schemasBeaComLdCustorder.CustomerOrderReportDocument.CustomerOrderReport.CustomerOrder.BroadbandOrders.CUSTOMERORDER[] BroadBand;
public schemasBeaComLdCustorder.CustomerOrderReportDocument.CustomerOrderReport.CustomerOrder.WirelessOrders.CUSTOMERORDER[] Wireless;
public
schemasBeaComLdCustorder.CustomerOrderReportDocument.CustomerOrderReport.CustomerOrder Customers;
// Uncomment this declaration to access Global.app.
//
// protected global.Global globalApp;
//
// For an example of page flow exception handling see the example "catch" and "exception-handler"
// annotations in {project}/WEB-INF/src/global/Global.app
/**
* This method represents the point of entry into the pageflow
* @jpf:action
*/
protected Forward begin()
{
return new Forward( "success" );
}
/**
* Action encapsulating the control method :custOrdRpt
* @jpf:action
* @jpf:forward name="success" path="index.jsp"
* @jpf:catch method="exceptionHandler" type="Exception"
*/
public Forward custOrdRpt( CustOrdRptForm aForm )
throws Exception
{
schemasBeaComLdCustorder.CustomerOrderReportDocument var = myControl.custOrdRpt( aForm.myCustomer );
getRequest().setAttribute( "results", var );
Wireless = var.getCustomerOrderReport().getCustomerOrderArray(0).getWirelessOrders().getCUSTOMERORDERArray() ;
BroadBand = var.getCustomerOrderReport().getCustomerOrderArray(0).getBroadbandOrders().getCUSTOMERORDERArray() ;
Customers = var.getCustomerOrderReport().getCustomerOrderArray(0);
return new Forward( "success" );
}
/**
* @jpf:action
* @jpf:forward name="success" path="custOrdRpt.jsp"
*/
public Forward custOrdRptLink()
throws Exception
{
return new Forward( "success" );
}
/**
* @jpf:exception-handler
* @jpf:forward name="errorPage" path="/error.jsp"
*/
protected Forward exceptionHandler( Exception ex, String actionName, String message, FormData form )
{
String displayMessage = "An exception occurred in the action " + actionName;
getRequest().setAttribute( "errorMessage", displayMessage );
return new Forward( "errorPage" );
}
/**
* FormData class CustOrdRptForm
* FormData get and set methods may be overwritten by the Form Bean editor.
*/
public static class CustOrdRptForm extends FormData
{
private java.lang.String myCustomer;
public void setMyCustomer( java.lang.String myCustomer )
{
this.myCustomer = myCustomer;
}
public java.lang.String getMyCustomer()
{
return myCustomer;
}
}
}
Now that variables are available to hold query results, the last step is to modify index.jsp to display your results. In the custOrdRpt folder double-click on index.jsp (Figure 42).
Figure 42 WebLogic Workshop Design View of index.jsp
Three things need to be added to index.jsp:
The following sections walk you through the index.jsp editing process.
First, several labels need to be added to index.jsp.
Go to the source view. Open the index.jsp file. Near the end of that file find and replace the long line beginning with:
<%Object res = request.getAttribute ...
Next, a HTML table needs to be added to the page to hold customer information (in an RDBMS application, customer information would represent the master and customer orders the detail).
CUSTOMER (Figure 43).Figure 43 Java Server Page (index.jsp) After Adding Field Labels
Figure 44 Creating a HTML Table in WebLogic Workshop
index.jsp in Source View.Figure 45 Selecting a Cell in WebLogic Workshop Table Grid
<table border="1">
<tr>
<td>First Name</td>
<td> </td>
</tr>
<tr>
<td>Last Name</td>
<td> </td>
</tr>
<tr>
<td>Customer ID</td>
<td> </td>
</tr>
<tr>
<td>Email Address</td>
<td> </td>
</tr>
</table>
Figure 46 Data Palette Page Flow Data Components
Figure 47 Populating WebLogic Workshop HTML Table with Customer Data Element
Figure 48 shows a fully configured customer information table.
Figure 48 Design View of Customer ID Table in index.jsp
WebLogic Workshop repeater fields make it very easy to insert arrays of data such as Wireless and BroadBand order information. (For details see the topic "To Add a Repeater to a JSP File" in the chapter Using Workshop Controls to Develop Liquid Data Applications in the Application Developer's Guide.)
Using your cursor, highlight the return after BroadBand (Figure 49).
Figure 49 Populating a JSP With an Array Containing BroadBand Order Data Elements
Figure 50 Selecting Fields for NetUI Repeater Element
Figure 51 Setting Format for NetUI Repeater Element
Congratulations. Your application is completed. To test it:
When finished, your results page contain the same data as is shown in Figure 52.
Figure 52 Results Page After Query is Run
This concludes the Liquid Data Quick Start tutorial. If you followed along with the instructions, you successfully:
All the files associated with the Liquid Data query and web application are generated automatically. Table 8 provides some details. Notice that of the nearly 500 lines of code required to produce this rather simple application, only 13 lines were created by hand.
Now that you are somewhat familiar with the basics of creating Liquid Data queries using the Data View Builder, the following may be of increased interest:
|
|
|
