Data Manipulation and More for HTML DB Applications

In this conclusion to a three-part series covering the addition of validations, computations, and processes to an HTML DB application, you will learn about data manipulation, manually creating a web services process, and more. This article is excerpted from chapter 13 of the Oracle HTML DB Handbook, written by Lawrence Linnemeyer and Bradley Brown (McGraw-Hill, 2006; ISBN: 0072257687).

Data Manipulation

The Data Manipulation type processes are called declarative processes because the HTML DB engine will create processes from declarations provided by the developer. These processes perform inserts, updates, and deletes without the developer having to write the actual DML statements. The actual code is generated based on information provided by the developer. These processes are then used with single-row form pages and multirow form pages.

There are several categories of Data Manipulation processes. With a single-row form page, you use an Automated Row Fetch category process to fetch rows and populate your fields on the rendering of the page. You use an Automated Row Processing (DML) category process when the page is submitted—to process inserts, updates, and deletes.

Multirow edit forms are implemented as a variation of a report, so the fetching of data into the form during the page rendering does not require a separate process; it is actually handled by the report region. Several categories of Data Manipulation processes are specifically designed for working with multirow forms. Two categories—Multi Row Update and Multi Row Delete—are used to perform just what their names imply: updates and deletes. The final category of Data Manipulation processes is used to add additional blank rows to the report so that new rows can be inserted into the table.

These processes are limited to operating on a single table or view. Additionally, the table can have at most a two-column primary key. If you are going to use this type of process, it is best to have the wizards create it for you. Invoke the wizards by creating a new page or a new region. If you need to deal with more complex structures than the wizards will allow, take the approach discussed earlier in the section on PL/SQL type processes.

Web Services

Web Services processes are used to submit parameters to and retrieve results from a Web Service Reference. Web Service References were covered in Chapter 7 as part of the shared components of an application. Once you have a valid Web Service Reference, you can create a process to utilize the web service.

Once again, although you can manually create a process for a web service, it is recommended that you use the wizards to create all the elements needed to use a web service. Once you finish creating a Web Service Reference, you will be given the opportunity to start a wizard either to create a form using the web service or to create a form and a report using the web service. You can also start the wizard by running a page and clicking on the Create link on the Developer’s Toolbar, then selecting the Region on This Page option, selecting the Form option, and finally selecting either the Form on Web Service option or the Form and Report on Web Service option.

If the results of the web service will be single values, you want to use the just the form. If the results of the web service will be multiple rows of results, you want to use the form and report. The wizards will use the information in the Web Service Reference to create the required input fields, the required output fields or report, and the process to submit the input fields and display the output.

{mospagebreak title=Manually Creating a Web Services Process}  

To create a Web Services process manually, after starting the Create Page Process Wizard, select the Web Services type. In the next step of the wizard, you will supply a name and a sequence. You can accept the defaults for the Type field and the Point field, which will be On Submit – After Computations and Validations.

Many web services offer different operations from the same Web Service Reference. For instance, a ZIP code web service may offer an operation to return the city for a ZIP code, an operation to return the city and state, or an operation to return the distance between two ZIP codes. In the next step of the wizard, you will select the Web Service Reference from an LOV and then a particular operation from an LOV, which will be based on the reference you selected.

When you select a particular operation, the wizard will provide two additional sections—one for the input parameters and one for the output parameters, as shown next. The source for the input parameter can be either a static value or an item on your page. Some web services are subscription services and you must provide a username and a password. For these, you use a static value that your users never see. For the remaining items—the ones you want your users to be able to enter values for—you will want to use page items. In the Value field, you either enter the static value or the name of the page item.

For the output parameters, you need to specify whether to use items or collections. Items are used for web services that return a single record. Collections are used for a web service that returns multiple records in the results. The two final steps in the wizard for a Web Services process allow you to enter success and failure messages and any conditions under which you want the process to be evaluated.

{mospagebreak title=Form Pagination}

The Form Pagination process is used with a master detail page. It determines the next and previous master records and populates a field to display the positional count of the current master record (for example, “3 of 4”). This particular type of process is created when you use the wizard to create a master detail form.

Most of the time when your application uses one of these type processes, it is created by the Master Detail Wizard. However, if you understand what the process does, you may find a time when you want to create a process of this type manually. For instance, you could use a Form Pagination process on a page that displays a single record from a table and the process would handle the next-record and previous-record navigation for that table.

The process operates on a single table and should usually be defined to be evaluated after the header when the page is being rendered. The process takes the current primary key and determines, based on a specified sort order, the primary keys of the records that are logically before and after the current record.

You must already have an item on your page where the primary key of the table will be stored. Creating a Form Pagination process not only produces the process but also creates the following:

  1. A hidden field to hold the value of the primary key for the next master record
  2. A hidden field to hold the value of the primary key for the previous master record
  3. A Previous button with conditions to display only if there is a value in the previous primary key hidden field
  4. A Next button with conditions to display only if there is a value in the next primary key hidden field
  5. A display field for the current master record count (for example, “3 of 4”)
  6. A branch back to the same page, conditional on the Next button, that populates the item holding the primary key with the value from the item holding the primary key of the next record
  7. A branch back to the same page, conditional on the Previous button, that populates the item holding the primary key with the value from the item holding the primary key of the previous record

If you are manually using this processes, you would have a query whose WHERE clause references the item containing the primary key.

This explanation always refers to a single primary key on the table. However, the wizard and process can handle a primary key with two columns. In that case, the wizard would create two “next” and two “previous” hidden fields.

In the Create Page Process Wizard, after selecting the Form Pagination type process, you specify the table on which to base the process. Next, you specify the one or two columns that make up the primary key on the table and the existing page items where these keys will be. These items are the only ones that must exist prior to creating the process. Then, you must specify the region on your page where the wizard should create all the items specified previously. You will also specify one or two columns from the table that will be used to determine the ordering of the table. If you do not specify a column for ordering, the order will be determined by the primary key. Finally, you can specify a WHERE clause if you want to limit the records that will be included.

{mospagebreak title=Close Popup Window}

The final type of process, which is new to version 2.0, is the Close Popup Window type process. This process is used on a page that’s the source for a pop-up window. The process, when executed, will close the pop-up window and according to the wizard refresh the calling window. You can successfully use this process to close a pop-up window if there is no branch defined; however, the refreshing of the calling window does not occur.

In the process-creation wizard, when you select to create a process of this type, all you have to specify is its name, a sequence, and the point at which the process will be evaluated. If you want to add a condition to the process, you must edit the process after it is created.

Editing Processes

To edit a process, click on the name of the process on the Page Definition page. This will open the Edit Page Process page. The Edit Page Process page is primarily the same for all types of processes; the biggest difference is the Sources section, which is dependent on the process type.

Most of the information entered in the process-creation wizards can be changed through the edit page. However, the one thing that can never be changed is the process type. In addition to the elements defined during creation are the standard sections for Authorization, Configuration, and Comments.

One attribute found in the Processing Point section, in addition to the sequence and the processing point, is the Run Process field. This field has two choices that allow you to specify whether the process should be run once per page visit, which is the default, or once per session or when reset. The latter option is very useful for tasks that only need to happen once per unique visit to the application.

[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye