• Aucun résultat trouvé

Before beginning with the xsql:insert-requestaction, your first step is to under-stand how XML is posted. The action itself works the same—you specify the table and a stylesheet to transform the XML to the canonical form. What works differently is how the data arrives. With HTML forms, the key-value pairs arrive contained in the XML request element. In this case, the XML document arrives within the XML request.

To understand the difference, it is important to understand what an HTTPPOST looks like. When you hit Submit on an HTML form, your Web browser starts an HTTP transaction. There isn’t much mysterious about the transaction. In plain text, it sends the following message to the Web server:

POST /xsql/insert-request.xsql HTTP/1.0

The XSQL servlet receives the parameters and does the translation to XML. The data is inserted, and a result is returned. That is the complete HTTP transaction. If you can type fast enough, you can actually manually execute the exact same insertion that your Web browser performs when you fill out the form. Just enter telnet localhost 80 and start typing!

The case you are working at here is one in which you are receiving an XML docu-ment directly as part of the body of the HTTPPOSTrequest. In this case the transaction looks like the preceding request. The difference is that the XML is already formatted—

the XSQL servlet doesn’t need to conjure up XML out of a list of name-value pairs. As you will see, from here you simply have to transform the XML to the canonical format.

If you have been doing Web work for a while, you may be asking yourself: “The old way of submitting forms is great. Why should I bother with this new way?” There are a few reasons why posting XML in this manner is important. First, a lot of work often goes into transforming name-value pairs to a more usable data structure. In a lot of cases, the problem is figuring out how the different name-value pairs are related to each other. XML is simply a more powerful way to represent data than simple name-value pairs. The second most important reason is that a lot of Web services applications work on this principle. The XML is passed from a machine to your application over HTTP, and then you handle the XML. You will learn more about this in Chapter 16.

124 Chapter 7

N OT E You have probably heard a lot about Web services and a lot about Simple Object Access Protocol (SOAP). Per the preceding description, you can consider any two applications communicating over HTTP to be a Web service.

They tend to exchange XML because it is the best format for the job. SOAP is a protocol that encapsulates this basic architecture. You’ll learn more about Web services in Chapter 16.

At present, not all Web browsers will allow you to submit XML in HTTPPOST requests. Microsoft Internet Explorer will, so it is required for these examples. The first step is to construct the HTML form. Note that it invokes a Javascript function on submit.

var xmlhttp = new ActiveXObject (“Microsoft.XMLHTTP”);

xmlhttp.open(“POST”, “insert-request-xml.xsql”,false);

xmlhttp.send(xmldoc);

return xmlhttp;

}

function submitInfo(){

var xmldoc = new ActiveXObject (“Microsoft.XMLDOM”);

xmldoc.async = false;

<b>Type in an XML Document to Post:<b><br>

<TEXTAREA rows=”12” style=”width:100%” cols=”70” NAME=”xmldocText”>

<request>

<INPUT TYPE=”button” Value=”Post XML Document”

onclick=”submitInfo()”>

</BODY>

</HTML>

When the form is loaded in the browser, it looks like a normal form, as shown in Figure 7.4. It behaves differently, though. The Microsoft.XMLHTTPActiveX object is created to handle the transaction. In the present case, all of the data from the textareaelement is simply passed along. However, you aren’t limited to only text areas. You can have any HTML form elements and then just assemble them into the XML document as you like.

For this first example, you are using the exact same XML schema that you had to use in the preceding form examples. This makes the insert-request.xsqldocument very simple. Note that it uses the exact same stylesheet as was used in the earlier example.

<?xml version=”1.0”?>

This XML schema is overkill, though. The request and parameters elements are unnecessary for the purposes of this example. Instead, you can simplify the schema so that it looks like the following code. (At this point, you might also want to delete or modify the default for the text area in the HTML page.)

<newsletter-member>

<email>email value</email>

<name>name value</name>

<org>org value</org>

</newsletter-member>

Your new, simpler XML schema means that you need a new stylesheet. The stylesheet that follows will do the trick. The only change required in the XSQL document is the transformattribute. That should be set to xml-transform.xslor whatever name you choose.

Figure 7.4 XML-enabled form.

From here, updates and deletions can be created with the same steps. Your XML schema hasn’t changed, so you don’t need to create a new stylesheet. All that is needed is to create the update-request-xml.xsql and delete-request-xml.xsql files. Here is the update-request-xml.xsqlfile:

<?xml version=”1.0”?>

<?xml-stylesheet type=”text/xsl” href=”thanks.xsl” ?>

<page connection=”momnpup” xmlns:xsql=”urn:oracle-xsql”>

<xsql:update-request table=”newsletter” key-columns=”email”

transform=”xml-transform.xsl”/>

</page>

Here is the delete-request-xml.sqlfile:

<?xml version=”1.0”?>

<?xml-stylesheet type=”text/xsl” href=”thanks.xsl” ?>

<page connection=”momnpup” xmlns:xsql=”urn:oracle-xsql”>

<xsql:delete-request table=”newsletter” key-columns=”email”

transform=”xml-transform.xsl”/>

</page>