13
Developing Web Applications with PL/SQL

Handling Script Errors

Any errors in HTML t agging are handled by the browser. The PSP loading process does not check for them.

If you make a syntax error in the PL/SQL code, the loader stops and you must fix the error before continuing. Note that any previous version of the stored procedure can be erased when you attempt to replace it and the script contains a syntax error. You might want to use o ne database for prototyping and debugging, then load the final stored procedure into a different database for production. You can swi tch databases using a command-line flag, without changing any source code.

To handle databa se errors that occur when the script runs, you can include PL/SQL exception-handling code within a PSP file, and have any unhandled e xceptions bring up a special page. The page for unhandled exceptions is another PL/SQL server page with extension .psp. The error procedure does not receive any parameters, so to determine the cause of the error, it can call the SQLCODE and SQLERRM functions.

You can also display a standard HTML page without any scri pting when an error occurs, but you must still give it the extension .psp and load it into the database as a stored proc edure.

Naming the PL/SQL Stored Procedure in a PSP Script

Each top-level PL/SQL server page corresponds to a stored procedure with in the server. By default, the procedure is given the same name as the original file, with the .psp extension removed. T o name the procedure something else, include a include a <%@ plsql procedure="procname" %> directive.

Including the Contents of Other Files in a PSP Script

You can set up an include mechanism to pull in the contents of other files, typically containing either static HTML content or more PL/SQL scripting code. Include a <%@ include file="filename" %> directive at the point where the other file's content should appear. Because the files are processed at the point where you load the stored procedure into the database, the substitution is done only once, not whenever the page is served.

You can use any names and extensions for the included files. If the included files contain PL/SQL scripting code, they do not need their own set of directives to identify the procedure name, character set, and so on.

When specifying the names of fil es to the PSP loader, you must include the names of all included files also. Specify the names of included files before the names of any .psp files.

You can use this feature to pull in the same content, such as a navigation banner, into many different files. Or, you can use it as a macro capability to include the same section of script code i n more than one place in a page.

Declaring Vari ables in a PSP Script

If you need to use global variables within the script, you ca n include a declaration block inside the delimiters <%! %>. All the usual PL/SQL syntax is allowed within the block. The delimiters server as shorthand, letting you omit the DECLARE keyword. All the declarations are available to the code later on in the file.

You can specify multiple declaration blocks; internally, the y are all merged into a single block when the PSP file is made into a stored procedure.

You can also use explicit DECLARE blocks within the <% %> delimiters that are explained later. Thes e declarations are only visible to the following BEGIN/END block.

Specifying Executable Statements in a PSP Script

Yo u can include any PL/SQL statements within the delimiters <% %>. The statements can be complete, or clauses o f a compound statement, such as the IF part of an IF-THEN-ELSE statement. Any variables declared within DECLARE blocks are only visible to the following BEGIN/END block.

Substituting an Expression Result in a PSP Script

To include a value that depends upon the result of a PL/SQL expression, include the expression within the delimiters & lt;%= %>. Because the result is always substituted in the middle of text or tags, it must be a string value or be able to be cast to a string. For any types that cannot be implicitly cast, such as DATE, pass the value to the PL/SQL TO_CHAR function.

The content between the <%= %> delimiters is processed by the HTP.PRN function, which trims any leading or trailing whitespace and requires that you quote any lit eral strings.

Conventions for Quoting and Escap ing Strings in a PSP Script

When values specified in PSP attributes are used for PL /SQL operations, they are passed exactly as you specify them in the PSP file. If PL/SQL requires a single-quoted string, you must spe cify the string with the single quotes around it -- and surround the whole thing with double quotes.

You can also nest single-quoted strings inside single quotes. In this case, you must escape the nes ted single quotes by specifying the sequence \'.

Most characters and character sequences can be included in a PSP file without being changed by the PSP loader. To include the sequence %>, specify the escape sequence %\>. To include the sequence <%, specify the escape sequence <\% .

Including Comments in a PSP Script

To put a comment in the HTML portion of a PL/SQL server page, for the benefit of people readi ng the PSP source code, use the syntax:

<%-- Comment text --%>
;

These comments do not appear in the HTML output from the PSP.

To create a comment that is visible in the HTML output, place the comment in the HTML portio n and use the regular HTML comment syntax:

<!-- Comment text -->

To include a comment inside a PL/SQL block within a PSP, you can use the normal PL/SQ L comment syntax.

For example, here is part of a PSP file showing several kinds of comments :

<p>Today we introduce our new model XP-10.
<%--
This is the project with code name "Secret Project".
People viewing the HTML page will not see this
 comment.
--%>
<!--
Some pictures of the XP-10.
People viewing the HTML page will see this comment.
-->
<%
for image_file in (select pathname, width, height, description
  from image_library where model_num = 'X
P-10')
-- Comments interspersed with PL/SQL statements.
-- People viewing the HTML page w
ill not see this comment.
loop
%>
<img src="<%= image_file
.pathname %>" width=<% image_file.width %>
height=<% image_file.height %> alt="<% image_file.
description %>">
<br>
<%
end loop;
%>

Retrieving a Result Set from a Query in a PSP Script

If your background is in HTML design, he re are a few examples of retrieving data from the database and displaying it.

To display th e results of a query that returns multiple rows, you can iterate through each row of the result set, printing the appropriate columns using HTML list or table tags:

<% FOR item IN (SELECT * FROM some_table) LOOP %>
  <TR>
  <TD><%= item.col1 %></TD>
  <TD>
;<%= item.col2 %></TD>
  </TR>
<% END LOOP; %>

If you want to print out an entire database table in one operation, you can call th e OWA_UTIL.TABLEPRINT or OWA_UTIL.CELLSPRINT procedures from the PL/SQL Web toolkit:

<% OWA_UTIL.TABLEPRINT(CTABLE => 'some_table', CATTRIBUTES => 'border=2', 
CCOLUMNS => 'col1, col2',
CCLAUSES => 'WHERE col1 > 5'); %>

htp.tableOpen('border=2');

owa_util.cellsprint( 'select col1, col2 from some_table where col1 > 5');
htp.tableClose;

Coding Tips f or PSP Scripts

To share procedures, constants, and types across different PL/SQL se rver pages, compile them into a separate package in the database using a plain PL/SQL source file. Although you can reference package d procedures, constants, and types from PSP scripts, the PSP scripts can only produce standalone procedures, not packages.

To make things easier to maintain, keep all your directives and declarations together near the beginn ing of a PL/SQL server page.

Syntax of PL/SQL Server Page Elements

You can fi nd examples of many of these elements in "Examples of PL/SQL Server Pages".

Page Directive

Specifies characteristics of the PL/SQL server pa ge:

• What scripting language it uses.
• What type of information (MIME type) it produces.
• What code to run to handle all uncaught exceptions. This might be an HTML file with a friendly message, renamed to a .psp file. You must specify this same file name in the loadpsp command that compiles the main PSP file. You must specify exactly the same name in both the errorPage directive and in the loadpsp command, including any relative pa th name such as ../include/.

<%@ page [language="PL/SQL"] [contentType="content type string"] charset="encoding" [errorPage="file.psp"] %>

<%@ plsql pr
ocedure="procedure name" %>

<%@ parameter="username" type="varchar2" default="'nobody'" %>

<%@ plsql parameter="parameter name" [type="PL/SQL type"] [default="value"] %>

<%@ include file="path name" %>

<%! PL/SQL declaration;
    [ PL/SQL declaration; ] ... %>

<% PL/SQL statement;
   [ PL/SQL statement; ] ... %>

<%= PL/SQL expression %>

loadpsp [ -replace ] -user username/password[@connect_string] 
    [ include_file_name ... ] [ error_file_name ] psp_file_name ...




To do a "create and replace" on the stored procedures, include the -replace f
lag.
 
The loader logs on to the database using the specified user name, password, and connec
t string. The stored procedures are created in the corresponding schema.
 
Include the names
of all the include files (whose names do not have the .psp extension) before the names of the PL/SQL server pages (whose
 names have the .psp extension). Also include the name of the file specified in the errorPage attribute of
the page directive. These filenames on the loadpsp command line must match exactly the names specified within the PSP include and page directives, including any relative path name such as ../include/.
 
For example:
loadpsp -replace -user scott/tiger@orcl banner.in
c error.psp display_order.psp




In this example:

The stored procedure is created in the database orcl. The database
is accessed as user scott with password tiger, both to create the stored procedure and when the stored procedure is executed.
banner.inc is a file containing boilerplate text and script code, that i
s included by the .psp file. The inclusion happens when the PSP is loaded into the database, not when the stored procedu
re is executed.
error.psp is a file containing code, text, or bot
h that is processed when an unhandled exception occurs, to present a friendly page rather than an internal error message.
display_order.psp contains the main code and text for the Web page. By defau
lt, the corresponding stored procedure is named DISPLAY_ORDER.
 
Running a PL/SQL Server Page Through a URL

 
Once the PL/SQL server page has been turned into a stored procedure, you can run it b
y retrieving an HTTP URL through a Web browser or other Internet-aware client program. The virtual path in the URL depends on the way
 the Web gateway is configured.
 
The parameters to the stored procedure are passed through e
ither the POST method or the GET method of the HTTP protocol. With the POST method, the parameters are passed directly from an HTML f
orm and are not visible in the URL. With the GET method, the parameters are passed as name-value pairs in the query string of the URL
, separated by & characters, with most non-alphanumeric characters in encoded format (such as %20 for a
 space). You can use the GET method to call a PSP page from an HTML form, or you can use a hard-coded HTML link to call the stored pr
ocedure with a given set of parameters.
 
Sample PSP URLs

 
Using METHOD=GE
T, the URL might look something like this:
http://sitename/<
em class="Italic">schemaname/pspname?parmname1=value1&am
p;parmname2=value2




Using METHOD=POST, the URL does not show the parameters:
http://sitename/schemaname/pspname




The METHOD=GET format is more convenient for debugging and allows visitors to pass exactly the sa
me parameters when they return to the page through a bookmark.
 
The METHOD=POST
 format allows a larger volume of parameter data, and is suitable for passing sensitive information that should not be displayed in t
he URL. (URLs linger on in the browser's history list and in the HTTP headers that are passed to the next-visited page.) It is not pr
actical to bookmark pages that are called this way.
 
Examples of PL/SQL Server Pages

 
This section shows how you might start with a very simple PL/SQL server page, and produce progressively more complicated versi
ons as you gain more confidence.
 
As you go through each step, you can use the procedures in
 "Loading the PL/SQL Server Page into the Database as a Stored Procedure" and "Running a PL/SQL Server Page Through a URL" to
compile the PSP files and try them in a browser.
 
Sample Table

 
In this example
, we use a very small table representing a product catalog. It holds the name of an item, the price, and URLs for a description and p
icture of the item.
Name       Type
---------- -------------
PRODUCT    VARCHAR2(100)
PRICE      NUMBER(7,2)
URL        VARCHAR2(200)
PICTURE    VARCHAR2(200)              

Guitar

455.5
http://auction.fictional_site.com/guitar.htm
http://auction.fictional_site.com/guit
ar.jpg
 
 
Brown shoe
79.95
http://retail.fictional_site.com/loafers.htm
http://retail.fictional_site.com/shoe.gif
<
/a> 
Radio
9.95
http://promo.fictional_site.com/freegift.htm
http://promo.fictional_site.com/alarmclock.jpg




Dumping the Sample Table

<
a name="1006834"> 
For your own debugging, you might want to display the complete contents of an SQL table. You can
 do this with a single call to OWA_UTIL.TABLEPRINT. In subsequent iterations, we use other techniques to get more contro
l over the presentation.
<%@ plsql procedure="show_catalog_simple" %>
<HTML>
<HEAD><TITLE>Show Contents of Catalog (Complete Dump)</TITLE></HEAD>
;
<BODY>
<% 
declare
dummy boolean;
begin
dummy := owa_util.tableprint('catalog','border');
end;
%>
</BODY>
</HTML>





Printing the Sample Table using a Loop

 
Next, we loop through the it
ems in the table and explicitly print just the pieces we want.

We could adjust the SELECT statement to retrieve only a subset of the rows or columns.
We could change the HTML or the location of the expressions to change the appearance of each item, or the orde
r in which the columns are shown.
At this early stage, we pick a very simple p
resentation, a set of list items, to avoid any problems from mismatched or unclosed table tags. 
<%@ plsql procedure="show_catalog_raw" %>
<HTML>
<HEAD><TITLE>S
how Contents of Catalog (Raw Form)</TITLE></HEAD>
<BODY>
<UL>
<% for item in (select * from catalog order by price desc) loop %>
<LI>
Item = <%= item.product %><BR>
price = <%= item.price %><BR>
URL = <I><%= item.url %></I><BR>
picture = <I><%= item.picture %>
</I>
<% end loop; %>
</UL>
</BODY>
</HTML>




Once the previous simple ex
ample is working, we can display the contents in a more usable format.

We use some HTML tags around certain values for emphasis.
Instead of
printing the URLs for the description and picture, we plug them into link and image tags so that the reader can see the picture and f
ollow the link. 
<%@ plsql procedure="show_catalog_pretty" %>
<H
TML>
<HEAD><TITLE>Show Contents of Catalog (Better Form)</TITLE></HEAD>
<BODY>
<UL>
<% for item in (select * from catalog order by price
 desc) loop %>
<LI>
Item = <A HREF="<%= item.url %>"><%= item.pro
duct %></A><BR>
price = <BIG><%= item.price %></BIG><BR>
<IMG SRC="<%= item.picture %>">
<% end loop; %>
</UL>
</BODY>
</HTML>




<
a name="1006899">
Allowing a User
 Selection

 
We have a dynamic page, but from a user point of view it
may still be dull. The results are always the same unless you update the catalog table.

To liven up the page, we can make it accept a minimum price, and present only the items that are more expen
sive. (Your customers' buying criteria may vary.)
When the page is displayed i
n a browser, by default the minimum price is 100 units of the appropriate currency. Later, we will see how to allow the user to pick
a minimum price. 
<%@ plsql procedure="show_catalog_partial" %>
<
;%@ plsql parameter="minprice" default="100" %>

<HTML>
&l
t;HEAD><TITLE>Show Items Greater Than Specified Price</TITLE></HEAD>
<BODY>
<P>This report shows the items whose price is greater than <%= minprice %>.
<UL>
;
<% for item in (select * from catalog where price > minprice order by price 
desc) loop %>
<LI>
Item = <A HREF="<%= item.url %>"><%= item.product %></A><BR&
gt;
price = <BIG><%= item.price %></BIG><BR>
<IMG SRC="<%=
item.picture %>">
<% end loop; %>
</UL>
</BODY
>
</HTML>




This technique
 of filtering results is fine for some applications, such as search results, where users might worry about being overwhelmed by choic
es. But in a retail situation, you might want to use an alternative technique so that customers can still choose to purchase other it
ems.

Instead of filtering the results through a WHERE clause, we can retrieve the entire result set, then take different actions for different returned rows.

We can change the HTML to highlight the output that meets their criteria. In this case, we use the bac
kground color for an HTML table row. We could also insert a special icon, increase the font size, or use some other technique to call
 attention to the most important rows.
At this point, where we want to present
 a specific user experience, it becomes worth the trouble to lay out the results in an HTML table. 
<%@ plsql procedure="show_catalog_highlighted" %>
<%@ plsql parameter="minprice" default="100" %&
gt;
<%! color varchar2(7); %>

<HTML>
<HEAD><TITLE>Show Items Greater Than Specified Price</TITLE></HEAD>
<BODY>
<
a name="1018220"><P>This report shows all items, highlighting those whose price is
 greater than <
%= minprice %>.
<TABLE BORDER>
<TR>
<TH>Produc
t</TH>
<TH>Price</TH>
<TH>Picture</TH>
</TR>
<%
for item in (select * from catalog order by price desc) loop
  if item.price > minprice then
    color := '#CCCCFF';
  else
    color := '#CCCCCC';
  end if;
%>
<TR BGCOLOR
="<%= color %>">
<TD><A HREF="<%= item.url %>"><%= item.product %></A>&l
t;/TD>
<TD><BIG><%= item.price %></BIG></TD>
<TD>&
lt;IMG SRC="<%= item.picture %>"></TD>
</TR>
<% end loop; %>
<
a name="1018242"></TABLE>
</BODY>
</HTML>





Sample HTML Form to Call a PL/SQL Server Page

 
Here is a bare-bones HTML form that allows someone to enter a price, and then calls the SHOW_CATALOG_PARTIAL stored p
rocedure passing the entered value as the MINPRICE parameter.
 
To avoid coding
the entire URL of the stored procedure in the ACTION= attribute of the form, we can make the form a PSP file so that it
goes in the same directory as the PSP file it calls. Even though this HTML file has no PL/SQL code, we can give it a .psp extension and load it as a stored procedure into the database. When the stored procedure is run, it just displays the HTML exactly
as it appears in the file.
<html>
<body>
<form method="POST" action="show_catalog_partial">
<p>Enter the minimum price you want to pay
:
<input type="text" name="minprice">
<input type="submit" value="Submit">
</form>
</body>
</html>










Note:  
An HTML form is different from other forms you might produce wi
th tools and programming languages. It is part of an HTML file, delimited by <FORM> and </FORM>
 tags, where someone can make choices and enter data, then transmit those choices to a server-side program using the CGI protocol. 
To produce a complete application using PSP, you might need to learn the syntax of <I
NPUT>, <SELECT>, and other HTML tags related to forms.

 
Including JavaScript in a PSP File
 
To produce an elaborate HTML file, perhaps including dynamic content such as JavaScript, you can simplify the sourc
e code by implementing it as a PSP. This technique avoids having to deal with nested quotation marks, escape characters, concatenated
 literals and variables, and indentation of the embedded content.
 
For example, here is how
an HTML file containing JavaScript might be generated using a PSP:
<%@ page language="PL
/SQL" %>
<%@ plsql procedure="graph" %>
<%! 
-- Begin w
ith a date that does not exist in the audit table
last_timestamp date := sysdate + 1;
%&g
t;
<html>
<head>
<title>Usage Statistics</titl
e>
<script language="JavaScript">
<!--
d=document

// Draw a horizontal graph line using a graphic that is stretched
// by
 a scaling factor.
function graph(howmuch)
{
  preamble = "<img
src='/images/graph_line.gif' height='8' width='"
  climax = howmuch * 4;
  denouement = "
'> (" + howmuch + ")\n"
  d.write( preamble + climax + denouement )
}
// -->
</script>
</head>
<body text="#00000
0" bgcolor="#FFFFFF">
<h1>Usage Statistics</h1>

<
;table border=1>

<%
-- For each day, count how many times ea
ch procedure was called.
for item in (select trunc(time_stamp) t, count(*) n, procname p

  from audit_table group by trunc(time_stamp), procname
  order by trunc(time_stamp) desc, procname)
loop
-- At the start of each day's data, print the date.
  if item.t != last_
timestamp then
    htp.print('<tr><td colspan=2><font size="+2">');

 htp.print(htf.bold(item.t));
    htp.print('</font></td></tr>');
    l
ast_timestamp := item.t;
end if;
%>

<t
r><td><%= item.p %></a>:
<td>
<!-- Render an image of varia
ble width to represent the data value. -->
<script language="JavaScript">
<!-
-
graph(<%= item.n %>)
// -->
</script>
</td>
</tr>

<% end loop; %>

</table>

</body>
&l
t;/html>




Coding this procedure as a regular PL/SQL stored proc
edure would result in convoluted lines with doubled apostrophes, such as this:
htp.print('p
reamble = 
          "<img src=''/images/graph_line.gif'' height=''8'' width=''"');



Debugging PL/SQL Server Page P
roblems

 
As you begin experimenting with PSP, and as you adapt your f
irst simple pages into more elaborate ones, keep these guidelines in mind when you encounter problems:

The first step is to get all the PL/SQL syntax and PSP directive syntax right. If you make a
 mistake here, the file does not compile. 

Make sure you use semic
olons to terminate lines where required.
If a value must be quoted, quote it.
You might need to enclose a single-quoted value (needed by PL/SQL) inside double quotes (needed by PSP).
Mistakes in the PSP directives are usually reported through PL/SQL syntax messages. Check that your direct
ives use the right syntax, that directives are closed properly, and that you are using the right element (declaration, expression, or
 code block) depending on what goes inside it.
PSP attribute names are case-se
nsitive. Most are specified in all lowercase; contentType and errorPage must be specified as mixed-case.
The next step is to run the PSP file by requesting its URL in a Web br
owser. At this point, you might get an error that the file is not found. 

Make sure you are requesting the right virtual path, depending on the way the Web gateway is configured. Typically, the path
includes the hostname, optionally a port number, the schema name, and the name of the stored procedure (with no .psp ext
ension).
Remember, if you use the -replace option when compiling
the file, the old version of the stored procedure is erased. So, after a failed compilation, you must fix the error or the page is no
t available. You might want to test new scripts in a separate schema until they are ready, then load them into the production schema.

If you copied the file from another file, remember to change any procedure na
me directives in the source to match the new file name.
Once you get one file-
not-found error, make sure to request the latest version of the page the next time. The error page might be cached by the browser. Yo
u might need to press Shift-Reload in the browser to bypass its cache.
<
/a>When the PSP script is run, and the results come back to the browser, use standard debugging techniques to check for and correct w
rong output. The tricky part is to set up the interface between different HTML forms, scripts, and CGI programs so that all the right
 values are passed into your page. The page might return an error because of a parameter mismatch. 

To see exactly what is being passed to your page, use METHOD=GET in the calling form s
o that the parameters are visible in the URL.
Make sure that the form or CGI p
rogram that calls your page passes the correct number of parameters, and that the names specified by the NAME= attribute
s on the form match the parameter names in the PSP file. If the form includes any hidden input fields, or uses the NAME=
 attribute on the Submit or Reset buttons, the PSP file must declare equivalent parameters.
Make sure that the parameters can be cast from string into the correct PL/SQL types. For exam
ple, do not include alphabetic characters if the parameter in the PSP file is declared as a NUMBER.
Make sure that the query string of the URL consists of name-value pairs, separated by equals signs
, especially if you are passing parameters by constructing a hard-coded link to the page.
If you are passing a lot of parameter data, such as large strings, you might exceed the volume that can be passed with METHOD=GET. You can switch to METHOD=POST in the calling form without changing your PSP file.
Although the loadpsp command reports line numbers correctly when there is a synt
ax error in your source file, line numbers reported for runtime errors refer to a transformed version of the source and do not match
the line numbers in the original source. When you encounter errors like these, that produce an error trace instead of the expected We
b page, you will need to locate the error through exception handlers and by printing debug output.
 
Putting an Application usin
g PL/SQL Server Pages into Production

 
When you start developing an a
pplication with PSP, you may spend most of your time getting the logic correct in the script. Before putting the application into pro
duction, consider other issues such as usability and download speed:

Pages can be rendered faster in the browser if the HEIGHT= and WIDTH= attributes are specified for a
ll images. You might standardize on picture sizes, or store the height and width of images in the database along with the data or URL
.
For viewers who turn off graphics, or who use alternative browsers that read
 the text out loud, include a description of significant images using the ALT= attribute. You might store the descriptio
n in the database along with the image.
Although an HTML table provides a good
 way to display data, a large table can make your application seem slow. Often, the reader sees a blank page until the entire table i
s downloaded. If the amount of data in an HTML table is large, consider splitting the output into multiple tables.
If you set text, font, or background colors, test your application with different combinations o
f browser color settings: 

Test what happens if you override just
the foreground color in the browser, or just the background color, or both.
Ge
nerally, if you set one color (such as the foreground text color), you should set all the colors through the <BODY> tag, to avoid hard-to-read combinations like white text on a white background.
<
/a>If you use a background image, specify a similar background color to provide proper contrast for viewers who do not load graphics.

If the information conveyed by different colors is crucial, consider using so
me other method instead of or in addition to the color change. For example, you might put a graphic icon next to special items in a t
able. Some of your viewers may see your page on a monochrome screen, or on browsers that cannot represent different colors. (Such bro
wsers might fit in a shirt pocket and use a stylus for input.)
Provi
ding context information prevents users from getting lost. Include a descriptive <TITLE> tag for your page. If the
 user is partway through a procedure, indicate which step is represented by your page. Provide links to logical points to continue wi
th the procedure, return to a previous step, or cancel the procedure completely. Many pages might use a standard set of links that yo
u embed using the include directive.
In any entry fields, users might enter in
correct values. Where possible, use select lists to present a set of choices. Validate any text entered in a field before passing it
to SQL. The earlier you can validate, the better; a JavaScript routine can detect incorrect data and prompt the user to correct it be
fore they press the Submit button and make a call to the database.
Browsers tend to be lenient when displaying incorrect HTML. But what looks OK in one browser might look bad or might not display at
 all in another browser. 

Pay attention to HTML rules for quotatio
n marks, closing tags, and especially for anything to do with tables.
Minimize
 the dependence on tags that are only supported by a single browser. Sometimes you can provide an extra bonus using such tags, but yo
ur application should still be usable with other browsers.
You can check the v
alidity, and even in some cases the usability, of your HTML for free at many sites on the World Wide Web.
 
Enabling PL/SQL Web
Applications for XML

 
You might find that a PL/SQL Web application ne
eds to accept data in XML format, or produce tagged output that is XML rather than HTML.
 
Wh
en displaying output, you can set the MIME type of the Web page to text/xml so that an XML-enabled browser or other Web
client software can render it as XML.
 
You can also use a number of built-in features like t
he XMLTYPE type, DBMS_XMLQUERY and DBMS_XMLSAVE packages, and SYS_XMLGEN and SYS_XMLAGG functions within your application. For information about these features, see Oracle XML Developer's Kit Programmer's Guide.










Previous<
/a>


Next


Copyright © 1996, 2003 Oracle Corporation

All Rights Reserved.





Home


Book List



Contents


Index


Master&nb
sp;Index


Feedback