Youll learn all about stylesheets in Chapter 13, but you probably want a brief
description of what is going on here. The root element of the XML document is called
page, so the page template in the stylesheet is processed first. That template is every-
thing from <xsl:template match=page> to the next </xsl:template> tag.
All of the static HTML in the template is written out more or less verbatim. The second
template, ROWSET/ROW, is called inside the table. It defines how the values for each
row in the result set should be displayed. As you can see from the screenshot, this
template is called for each row that was returned in the result set. If you change the
queries so more rows are returned, they will all be displayed.
If you look at the stylesheet, the majority of the code is HTML. It also falls out very
logicallythe dynamic data appears amid the static HTML, precisely where you want
it to. The principle part of the XSQL page is a SQL query. At the beginning of this sec-
tion, it was stated that you only really needed a SQL statement and a way to turn the
results to HTML. The XSQL solution is very close to this. You will need to learn about
XSQL and XSLT, but notice that there has been no mention of Java, JSP, JDBC, business
logic, or anything else having to do with the middle tier. XSQL handles all of those
details for you.
This takes care of getting data from the database, but what about putting data into
it? You can also do that with XSQL. You use a different action, called <xsql:dml>.
Instead of specifying a select statement, you issue a statement that will modify the
data. As youll see in Chapter 14, you can use it in conjunction with forms to create edi-
tors. XSQL also provides you with built-in ways to call stored procedures.
You may be looking at this and thinking, Simple! . . . but maybe a little too
simple . . . . Of course, the simple architecture isnt going to be good enough for all
problems. But that doesnt mean that you cant use XSQL to solve harder problems that
involve multiple queries or complex validation before putting data into the database.
Luckily, you can easily extend XSQL. Remember the <xsql:query> that you saw in
the same page? You can write your own special actions that you can use just like that
one. The action handler code that processes the action is written in Java. Your action
handler code can do whatever it likes, and you can pass to it any type of data you like
from the XSQL page. As with the <xsql:dml> action, you can also make use of para-
meters passed on by the user. The only expectation is that the action handler generate
XML to be added to the datagram. Then, a stylesheet specified in the XSQL page can be
used to convert the datagram for presentation. Figure 1.5 diagrams the XSQL architec-
ture with action handlers.
There is one final trick up XSQLs sleeve. You arent limited strictly to text data! As
youll see in Chapter 19, you can use serializers to produce images and PDF docu-
ments. Once again, XSQL can be easily extended to conquer tough problems. The
XSQL architecture with serializers is specified in Figure 1.6. The serializer can be used
to control what is written as the final output.
XSQL makes it very easy to create simple database-driven Web pages. For the more
complex cases, you can use custom action handlers and serializers to extend the archi-
tecture. Your custom code works seamlessly with the rest of XSQL, so you dont give
up XSQLs elegance and simplicityyou just augment it. XSQL becomes even more
powerful when you use it in conjunction with other Oracle technologies, such as Ora-
cle Text and Oracle XML DB. Youll read more about that in the next section.
271209 Ch01.F 12/9/02 2:00 PM Page 10