You’ll  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 logically—the 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 you’ll 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 isn’t going to be good enough for all problems. But that doesn’t mean that you can’t 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 XSQL’s sleeve. You aren’t limited strictly to text data! As you’ll 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 don’t give up XSQL’s elegance and simplicity—you 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. You’ll read more about that in the next section. 10 Chapter 1 271209 Ch01.F  12/9/02  2:00 PM  Page 10