Developer’s Guide Borland Delphi 7 for Windows PHẦN 8 docx

Creating multi-tiered applications
31-39
Writing Web-based client applications
Creating Web pages with an InternetExpress page producer
Each InternetExpress page producer generates an HTML document that appears in
the browsers of your application’s clients. If your application includes several
separate Web documents, use a separate page producer for each of them.
The InternetExpress page producer (TInetXPageProducer) is a special page producer
component. As with other page producers, you can assign it as the Producer property
of an action item or call it explicitly from an OnAction event handler. For more
information about using content producers with action items, see “Responding to
request messages with action items” on page 34-8. For more information about page
producers, see “Using page producer components” on page 34-14.
The InternetExpress page producer has a default template as the value of its
HTMLDoc property. This template contains a set of HTML-transparent tags that the
InternetExpress page producer uses to assemble an HTML document (with
embedded javascript and XML) including content produced by other components.
Before it can translate all of the HTML-transparent tags and assemble this document,
you must indicate the location of the javascript libraries used for the embedded
javascript on the page. This location is specified by setting the IncludePathURL
property.
You can specify the components that generate parts of the Web page using the Web
page editor. Display the Web page editor by double-clicking the Web page
component or clicking the ellipsis button next to the WebPageItems property in the
Object Inspector.
The components you add in the Web page editor generate the HTML that replaces
one of the HTML-transparent tags in the InternetExpress page producer’s default
template. These components become the value of the WebPageItems property. After
adding the components in the order you want them, you can customize the template
to add your own HTML or change the default tags.
Using the Web page editor

The Web page editor lets you add Web items to your InternetExpress page producer
and view the resulting HTML page. Display the Web page editor by double-clicking
on a InternetExpress page producer component.
Note
You must have Internet Explorer 4 or better installed to use the Web page editor.
The top of the Web page editor displays the Web items that generate the HTML
document. These Web items are nested, where each type of Web item assembles the
HTML generated by its subitems. Different types of items can contain different
subitems. On the left, a tree view displays all of the Web items, indicating how they
are nested. On the right, you can see the Web items included by the currently selected
item. When you select a component in the top of the Web page editor, you can set its
properties using the Object Inspector.
Click the New Item button to add a subitem to the currently selected item. The Add
Web Component dialog lists only those items that can be added to the currently
selected item.
31-40
Developer’ s Guide
Writing Web-based client applications
The InternetExpress page producer can contain one of two types of item, each of
which generates an HTML form:
• TDataForm, which generates an HTML form for displaying data and the controls
that manipulate that data or submit updates.
Items you add to TDataForm display data in a multi-record grid (TDataGrid) or in a
set of controls each of which represents a single field from a single record
(TFieldGroup). In addition, you can add a set of buttons to navigate through data or
post updates (TDataNavigator), or a button to apply updates back to the Web client
(TApplyUpdatesButton). Each of these items contains subitems to represent
individual fields or buttons. Finally, as with most Web items, you can add a layout
grid (TLayoutGroup), that lets you customize the layout of any items it contains.
• TQueryForm, which generates an HTML form for displaying or reading

application-defined values. For example, you can use this form for displaying and
submitting parameter values.
Items you add to TQueryForm display application-defined
values(TQueryFieldGroup) or a set of buttons to submit or reset those values
(TQueryButtons). Each of these items contains subitems to represent individual
values or buttons. You can also add a layout grid to a query form, just as you can
to a data form.
The bottom of the Web page editor displays the generated HTML code and lets you
see what it looks like in a browser (Internet Explorer).
Setting Web item properties
The Web items that you add using the Web page editor are specialized components
that generate HTML. Each Web item class is designed to produce a specific control or
section of the final HTML document, but a common set of properties influences the
appearance of the final HTML.
When a Web item represents information from the XML data packet (for example,
when it generates a set of field or parameter display controls or a button that
manipulates the data), the XMLBroker property associates the Web item with the
XML broker that manages the data packet. You can further specify a dataset that is
contained in a dataset field of that data packet using the XMLDataSetField property. If
the Web item represents a specific field or parameter value, the Web item has a
FieldName or ParamName property.
You can apply a style attribute to any Web item, thereby influencing the overall
appearance of all the HTML it generates. Styles and style sheets are part of the
HTML 4 standard. They allow an HTML document to define a set of display
Creating multi-tiered applications
31-41
Writing Web-based client applications
attributes that apply to a tag and everything in its scope. Web items offer a flexible
selection of ways to use them:
• The simplest way to use styles is to define a style attribute directly on the Web

item. To do this, use the Style property. The value of Style is simply the attribute
definition portion of a standard HTML style definition, such as
color: red.
• You can also define a style sheet that defines a set of style definitions. Each
definition includes a style selector (the name of a tag to which the style always
applies or a user-defined style name) and the attribute definition in curly braces:
H2 B {color: red}
.MyStyle {font-family: arial; font-weight: bold; font-size: 18px }
The entire set of definitions is maintained by the InternetExpress page producer as
its Styles property. Each Web item can then reference the styles with user-defined
names by setting its StyleRule property.
• If you are sharing a style sheet with other applications, you can supply the style
definitions as the value of the InternetExpress page producer’s StylesFile property
instead of the Styles property. Individual Web items still reference styles using the
StyleRule property.
Another common property of Web items is the Custom property. Custom includes a
set of options that you add to the generated HTML tag. HTML defines a different set
of options for each type of tag. The VCL reference for the Custom property of most
Web items gives an example of possible options. For more information on possible
options, use an HTML reference.
Customizing the InternetExpress page producer template
The template of an InternetExpress page producer is an HTML document with extra
embedded tags that your application translates dynamically. Initially, the page
producer generates a default template as the value of the HTMLDoc property. This
default template has the form
<HTML>
<HEAD>
</HEAD>
<BODY>
<#INCLUDES> <#STYLES> <#WARNINGS> <#FORMS> <#SCRIPT>

</BODY>
</HTML>
The HTML-transparent tags in the default template are translated as follows:
<#INCLUDES> generates the statements that include the javascript libraries. These
statements have the form
<SCRIPT language=Javascript type="text/javascript" SRC="IncludePathURL/xmldom.js"> </SCRIPT>
<SCRIPT language=Javascript type="text/javascript" SRC="IncludePathURL/xmldb.js"> </SCRIPT>
<SCRIPT language=Javascript type="text/javascript" SRC="IncludePathURL/xmlbind.js"> </
SCRIPT>
31-42
Developer’ s Guide
Writing Web-based client applications
<#STYLES> generates the statements that defines a style sheet from definitions listed in
the Styles or StylesFile property of the InternetExpress page producer.
<#WARNINGS> generates nothing at runtime. At design time, it adds warning messages
for problems detected while generating the HTML document. You can see these
messages in the Web page editor.
<#FORMS> generates the HTML produced by the components that you add in the Web
page editor. The HTML from each component is generated in the order it appears in
WebPageItems.
<#SCRIPT> generates a block of javascript declarations that are used in the HTML
generated by the components added in the Web page editor.
You can replace the default template by changing the value of HTMLDoc or setting
the HTMLFile property. The customized HTML template can include any of the
HTML-transparent tags that make up the default template. The InternetExpress page
producer automatically translates these tags when you call the Content method. In
addition, The InternetExpress page producer automatically translates three
additional tags:
<#BODYELEMENTS> is replaced by the same HTML as results from the 5 tags in the default
template. It is useful when generating a template in an HTML editor when you want

to use the default layout but add additional elements using the editor.
<#COMPONENT Name=WebComponentName> is replaced by the HTML that the component
named WebComponentName generates. This component can be one of the components
added in the Web page editor, or it can be any component that supports the
IWebContent interface and has the same Owner as the InternetExpress page producer.
<#DATAPACKET XMLBroker=BrokerName> is replaced with the XML data packet obtained
from the XML broker specified by BrokerName. When, in the Web page editor, you see
the HTML that the InternetExpress page producer generates, you see this tag instead
of the actual XML data packet.
In addition, the customized template can include any other HTML-transparent tags
that you define. When the InternetExpress page producer encounters a tag that is not
one of the seven types it translates automatically, it generates an OnHTMLTag event,
where you can write code to perform your own translations. For more information
about HTML templates in general, see “HTML templates” on page 34-14.
Tip
The components that appear in the Web page editor generate static code. That is,
unless the application server changes the metadata that appears in data packets, the
HTML is always the same, no matter when it is generated. You can avoid the
overhead of generating this code dynamically at runtime in response to every request
message by copying the generated HTML in the Web page editor and using it as a
template. Because the Web page editor displays a <#DATAPACKET> tag instead of
the actual XML, using this as a template still allows your application to fetch data
packets from the application server dynamically.
Using XML in database applications
32-1
Chapter
32
Chapter32
Using XML in database applications
In addition to the support for connecting to database servers, Delphi lets you work

with XML documents as if they were database servers. XML (Extensible Markup
Language) is a markup language for describing structured data. XML documents
provide a standard, transportable format for data that is used in Web applications,
business-to-business communication, and so on. For information on Delphi’s support
for working directly with XML documents, see Chapter 37, “Working with XML
documents.”
Support for working with XML documents in database applications is based on a set
of components that can convert data packets (the Data property of a client dataset)
into XML documents and convert XML documents into data packets. To use these
components, you must first define the transformation between the XML document
and the data packet. Once you have defined the transformation, you can use special
components to
• convert XML documents into data packets.
• provide data from and resolve updates to an XML document.
• use an XML document as the client of a provider.
Defining transformations
Before you can convert between data packets and XML documents, you must define
the relationship between the metadata in a data packet and the nodes of the
corresponding XML document. A description of this relationship is stored in a
special XML document called a transformation.
Each transformation file contains two things: the mapping between the nodes in an
XML schema and the fields in a data packet, and a skeletal XML document that
represents the structure for the results of the transformation. A transformation is a
one-way mapping: from an XML schema or document to a data packet or from the
32-2
Developer’ s Guide
Defining transformations
metadata in a data packet to an XML schema. Often, you create transformation files
in pairs: one that maps from XML to data packet, and one that maps from data packet
to XML.

In order to create the transformation files for a mapping, use the XMLMapper utility
that ships in the bin directory.
Mapping between XML nodes and data packet fields
XML provides a text-based way to store or describe structured data. Datasets provide
another way to store and describe structured data. To convert an XML document into
a dataset, therefore, you must identify the correspondences between the nodes in an
XML document and the fields in a dataset.
Consider, for example, an XML document that represents a set of email messages. It
might look like the following (containing a single message):
<?xml version="1.0" standalone="yes" ?>
<email>
<head>
<from>
<name>Dave Boss</name>
<address></address>
</from>
<to>
<name>Joe Engineer</name>
<address></address>
</to>
<cc>
<name>Robin Smith/name>
<address></address>
</cc>
<cc>
<name>Leonard Devon</name>
<address></address>
</cc>
</head>
<body>

<subject>XML components</subject>
<content>
Joe,
Attached is the specification for the XML component support in Delphi.
This looks like a good solution to our buisness-to-buisness application!
Also attached, please find the project schedule. Do you think its reasonable?
Dave.
</content>
<attachment attachfile="XMLSpec.txt"/>
<attachment attachfile="Schedule.txt"/>
</body>
</email>
Using XML in database applications
32-3
Defining transformations
One natural mapping between this document and a dataset would map each e-mail
message to a single record. The record would have fields for the sender’s name and
address. Because an e-mail message can have multiple recipients, the recipient (<to>
would map to a nested dataset. Similarly, the cc list maps to a nested dataset. The
subject line would map to a string field while the message itself (<content>) would
probably be a memo field. The names of attachment files would map to a nested
dataset because one message can have several attachments. Thus, the e-mail above
would map to a dataset something like the following:
where the nested dataset in the “To” field is
the nested dataset in the “CC” field is
and the nested dataset in the “Attach” field is
Defining such a mapping involves identifying those nodes of the XML document that
can be repeated and mapping them to nested datasets. Tagged elements that have
values and appear only once (such as <content> </content>) map to fields whose
datatype reflects the type of data that can appear as the value. Attributes of a tag

(such as the AttachFile attribute of the attachment tag) also map to fields.
Note that not all tags in the XML document appear in the corresponding dataset. For
example, the <head> <head/> element has no corresponding element in the
resulting dataset. Typically, only elements that have values, elements that can be
repeated, or the attributes of a tag map to the fields (including nested dataset fields)
of a dataset. The exception to this rule is when a parent node in the XML document
maps to a field whose value is built up from the values of the child nodes. For
example, an XML document might contain a set of tags such as
<FullName>
<Title> Mr. </Title>
<FirstName> John </FirstName>
<LastName> Smith </LastName>
</FullName>
SenderName SenderAddress To CC Subject Content Attach
Dave Boss (DataSet) (DataSet) XML components (MEMO) (DataSet)
Name Address
Joe Engineer
Name Address
Robin Smith
Leonard Devon
Attachfile
XMLSpec.txt
Schedule.txt
32-4
Developer’ s Guide
Defining transformations
which could map to a single dataset field with the value
Mr. John Smith
Using XMLMapper
The XML mapper utility, xmlmapper.exe, lets you define mappings in three ways:

• From an existing XML schema (or document) to a client dataset that you define.
This is useful when you want to create a database application to work with data
for which you already have an XML schema.
• From an existing data packet to a new XML schema you define. This is useful
when you want to expose existing database information in XML, for example to
create a new business-to-business communication system.
• Between an existing XML schema and an existing data packet. This is useful when
you have an XML schema and a database that both describe the same information
and you want to make them work together.
Once you define the mapping, you can generate the transformation files that are used
to convert XML documents to data packets and to convert data packets to XML
documents. Note that only the transformation file is directional: a single mapping
can be used to generate both the transformation from XML to data packet and from
data packet to XML.
Note
XML mapper relies on two .DLLs (midas.dll and msxml.dll) to work correctly. Be
sure that you have both of these .DLLs installed before you try to use
xmlmapper.exe. In addition, msxml.dll must be registered as a COM server. You can
register it using Regsvr32.exe.
Loading an XML schema or data packet
Before you can define a mapping and generate a transformation file, you must first
load descriptions of the XML document and the data packet between which you are
mapping.
You can load an XML document or schema by choosing File|Open and selecting the
document or schema in the resulting dialog.
You can load a data packet by choosing File|Open and selecting a data packet file in
the resulting dialog. (The data packet is simply the file generated when you call a
client dataset’s SaveToFile method.) If you have not saved the data packet to disk, you
can fetch the data packet directly from the application server of a multi-tiered
application by right-clicking in the Datapacket pane and choosing Connect To

Remote Server.
You can load only an XML document or schema, only a data packet, or you can load
both. If you load only one side of the mapping, XML mapper can generate a natural
mapping for the other side.
Using XML in database applications
32-5
Defining transformations
Defining mappings
The mapping between an XML document and a data packet need not include all of
the fields in the data packet or all of the tagged elements in the XML document.
Therefore, you must first specify those elements that are mapped. To specify these
elements, first select the Mapping page in the central pane of the dialog.
To specify the elements of an XML document or schema that are mapped to fields in
a data packet, select the Sample or Structure tab of the XML document pane and
double-click on the nodes for elements that map to data packet fields.
To specify the fields of the data packet that are mapped to tagged elements or
attributes in the XML document, double-click on the nodes for those fields in the
Datapacket pane.
If you have only loaded one side of the mapping (the XML document or the data
packet), you can generate the other side after you have selected the nodes that are
mapped.
• If you are generating a data packet from an XML document, you first define
attributes for the selected nodes that determine the types of fields to which they
correspond in the data packet. In the center pane, select the Node Repository page.
Select each node that participates in the mapping and indicate the attributes of the
corresponding field. If the mapping is not straightforward (for example, a node
with subnodes that corresponds to a field whose value is built from those
subnodes), check the User Defined Translation check box. You will need to write
an event handler later to perform the transformation on user defined nodes.
Once you have specified the way nodes are to be mapped, choose Create|

Datapacket from XML. The corresponding data packet is automatically generated
and displayed in the Datapacket pane.
• If you are generating an XML document from a data packet, choose Create|XML
from Datapacket. A dialog appears where you can specify the names of the tags
and attributes in the XML document that correspond to fields, records, and
datasets in the data packet. For field values, the way you name them indicates
whether they map to a tagged element with a value or to an attribute. Names that
begin with an @ symbol map to attributes of the tag that corresponds to the record,
while names that do not begin with an @ symbol map to tagged elements that
have values and that are nested within the element for the record.
• If you have loaded both an XML document and a data packet (client dataset file),
be sure you select corresponding nodes in the same order. The corresponding
nodes should appear next to each other in the table at the top of the Mapping page.
Once you have loaded or generated both the XML document and the data packet and
selected the nodes that appear in the mapping, the table at the top of the Mapping
page should reflect the mapping you have defined.
32-6
Developer’ s Guide
Converting XML documents into data packets
Generating transformation files
To generate a transformation file, use the following steps:
1
First select the radio button that indicates what the transformation creates:
• Choose the Datapacket to XML button if the mapping goes from data packet to
XML document.
• Choose the XML to Datapacket button if the mapping goes from XML
document to data packet.
2
If you are generating a data packet, you will also want to use the radio buttons in
the Create Datapacket As section. These buttons let you specify how the data

packet will be used: as a dataset, as a delta packet for applying updates, or as the
parameters to supply to a provider before fetching data.
3
Click Create and Test Transformation to generate an in-memory version of the
transformation. XML mapper displays the XML document that would be
generated for the data packet in the Datapacket pane or the data packet that would
be generated for the XML document in the XML Document pane.
4
Finally, choose File|Save|Transformation to save the transformation file. The
transformation file is a special XML file (with the .xtr extension) that describes the
transformation you have defined.
Converting XML documents into data packets
Once you have created a transformation file that indicates how to transform an XML
document into a data packet, you can create data packets for any XML document that
conforms to the schema used in the transformation. These data packets can then be
assigned to a client dataset and saved to a file so that they form the basis of a file-
based database application.
The TXMLTransform component transforms an XML document into a data packet
according to the mapping in a transformation file.
Note
You can also use TXMLTransform to convert a data packet that appears in XML
format into an arbitrary XML document.
Specifying the source XML document
There are three ways to specify the source XML document:
• If the source document is an .xml file on disk, you can use the SourceXmlFile
property.
• If the source document is an in-memory string of XML, you can use the SourceXml
property.
• If you have an IDOMDocument interface for the source document, you can use the
SourceXmlDocument property.

Using XML in database applications
32-7
Converting XML documents into data packets
TXMLTransform checks these properties in the order listed above. That is, it first
checks for a file name in the SourceXmlFile property. Only if SourceXmlFile is an
empty string does it check the SourceXml property. Only if SourceXml is an empty
string does it then check the SourceXmlDocument property.
Specifying the transformation
There are two ways to specify the transformation that converts the XML document
into a data packet:
•Set the TransformationFile property to indicate a transformation file that was
created using xmlmapper.exe.
•Set the TransformationDocument property if you have an IDOMDocument interface
for the transformation.
TXMLTransform checks these properties in the order listed above. That is, it first
checks for a file name in the TransformationFile property. Only if TransformationFile is
an empty string does it check the TransformationDocument property.
Obtaining the resulting data packet
To cause TXMLTransform to perform its transformation and generate a data packet,
you need only read the Data property. For example, the following code uses an XML
document and transformation file to generate a data packet, which is then assigned
to a client dataset:
XMLTransform1.SourceXMLFile := 'CustomerDocument.xml';
XMLTransform1.TransformationFile := 'CustXMLToCustTable.xtr';
ClientDataSet1.XMLData := XMLTransform1.Data;
Converting user-defined nodes
When you define a transformation using xmlmapper.exe, you can specify that some
of the nodes in the XML document are “user-defined.” User-defined nodes are nodes
for which you want to provide the transformation in code rather than relying on a
straightforward node-value-to-field-value translation.

You can provide the code to translate user-defined nodes using the OnTranslate
event. The OnTranslate event handler is called every time the TXMLTransform
component encounters a user-defined node in the XML document. In the
OnTranslate event handler, you can read the source document and specify the
resulting value for the field in the data packet.
32-8
Developer’ s Guide
Using an XML document as the source for a provider
For example, the following OnTranslate event handler converts a node in the XML
document with the following form
<FullName>
<Title> </Title>
<FirstName> </FirstName>
<LastName> </LastName>
</FullName>
into a single field value:
procedure TForm1.XMLTransform1Translate(Sender: TObject; Id: String; SrcNode: IDOMNode;
var Value: String; DestNode: IDOMNode);
var
CurNode: IDOMNode;
begin
if Id = 'FullName' then
begin
Value = '';
if SrcNode.hasChildNodes then
begin
CurNode := SrcNode.firstChild;
Value := Value + CurNode.nodeValue;
while CurNode <> SrcNode.lastChild do
begin

CurNode := CurNode.nextSibling;
Value := Value + ' ';
Value := Value + CurNode.nodeValue;
end;
end;
end;
end;
Using an XML document as the source for a provider
The TXMLTransformProvider component lets you use an XML document as if it were
a database table. TXMLTransformProvider packages the data from an XML document
and applies updates from clients back to that XML document. It appears to clients
such as client datasets or XML brokers like any other provider component. For
information on provider components, see Chapter 30, “Using provider components.”
For information on using provider components with client datasets, see “Using a
client dataset with a provider” on page 29-24.
You can specify the XML document from which the XML provider provides data and
to which it applies updates using the XMLDataFile property.
TXMLTransformProvider components use internal TXMLTransform components to
translate between data packets and the source XML document: one to translate the
XML document into data packets, and one to translate data packets back into the
XML format of the source document after applying updates. These two
TXMLTransform components can be accessed using the TransformRead and
TransformWrite properties, respectively.
Using XML in database applications
32-9
Using an XML document as the client of a provider
When using TXMLTransformProvider, you must specify the transformations that these
two TXMLTransform components use to translate between data packets and the
source XML document. You do this by setting the TXMLTransform component’s
TransformationFile or TransformationDocument property, just as when using a stand-

alone TXMLTransform component.
In addition, if the transformation includes any user-defined nodes, you must supply
an OnTranslate event handler to the internal TXMLTransform components.
You do not need to specify the source document on the TXMLTransform components
that are the values of TransformRead and TransformWrite. For TransformRead, the
source is the file specified by the provider’s XMLDataFile property (although, if you
set XMLDataFile to an empty string, you can supply the source document using
TransformRead.XmlSource or TransformRead.XmlSourceDocument). For TransformWrite,
the source is generated internally by the provider when it applies updates.
Using an XML document as the client of a provider
The TXMLTransformClient component acts as an adapter to let you use an XML
document (or set of documents) as the client for an application server (or simply as
the client of a dataset to which it connects via a TDataSetProvider component). That is,
TXMLTransformClient lets you publish database data as an XML document and to
make use of update requests (insertions or deletions) from an external application
that supplies them in the form of XML documents.
To specify the provider from which the TXMLTransformClient object fetches data and
to which it applies updates, set the ProviderName property. As with the ProviderName
property of a client dataset, ProviderName can be the name of a provider on a remote
application server or it can be a local provider in the same form or data module as the
TXMLTransformClient object. For information about providers, see Chapter 30,
“Using provider components.”
If the provider is on a remote application server, you must use a DataSnap
connection component to connect to that application server. Specify the connection
component using the RemoteServer property. For information on DataSnap
connection components, see “Connecting to the application server” on page 31-23.
Fetching an XML document from a provider
TXMLTransformClient uses an internal TXMLTransform component to translate data
packets from the provider into an XML document. You can access this
TXMLTransform component as the value of the TransformGetData property.

32-10
Developer’ s Guide
Using an XML document as the client of a provider
Before you can create an XML document that represents the data from a provider,
you must specify the transformation file that TransformGetData uses to translate the
data packet into the appropriate XML format. You do this by setting the
TXMLTransform component’s TransformationFile or TransformationDocument property,
just as when using a stand-alone TXMLTransform component. If that transformation
includes any user-defined nodes, you will want to supply TransformGetData with an
OnTranslate event handler as well.
There is no need to specify the source document for TransformGetData,
TXMLTransformClient fetches that from the provider. However, if the provider
expects any input parameters, you may want to set them before fetching the data.
Use the SetParams method to supply these input parameters before you fetch data
from the provider. SetParams takes two arguments: a string of XML from which to
extract parameter values, and the name of a transformation file to translate that XML
into a data packet. SetParams uses the transformation file to convert the string of XML
into a data packet, and then extracts the parameter values from that data packet.
Note
You can override either of these arguments if you want to specify the parameter
document or transformation in another way. Simply set one of the properties on
TransformSetParams property to indicate the document that contains the parameters
or the transformation to use when converting them, and then set the argument you
want to override to an empty string when you call SetParams. For details on the
properties you can use, see “Converting XML documents into data packets” on
page 32-6.
Once you have configured TransformGetData and supplied any input parameters, you
can call the GetDataAsXml method to fetch the XML. GetDataAsXml sends the current
parameter values to the provider, fetches a data packet, converts it into an XML
document, and returns that document as a string. You can save this string to a file:

var
XMLDoc: TFileStream;
XML: string;
begin
XMLTransformClient1.ProviderName := 'Provider1';
XMLTransformClient1.TransformGetData.TransformationFile := 'CustTableToCustXML.xtr';
XMLTransformClient1.TransFormSetParams.SourceXmlFile := 'InputParams.xml';
XMLTransformClient1.SetParams('', 'InputParamsToDP.xtr');
XML := XMLTransformClient1.GetDataAsXml;
XMLDoc := TFileStream.Create('Customers.xml', fmCreate or fmOpenWrite);
try
XMLDoc.Write(XML, Length(XML));
finally
XMLDoc.Free;
end;
end;
Using XML in database applications
32-11
Using an XML document as the client of a provider
Applying updates from an XML document to a provider
TXMLTransformClient also lets you insert all of the data from an XML document into
the provider’s dataset or to delete all of the records in an XML document from the
provider’s dataset. To perform these updates, call the ApplyUpdates method, passing
in
• A string whose value is the contents of the XML document with the data to insert
or delete.
• The name of a transformation file that can convert that XML data into an insert or
delete delta packet. (When you define the transformation file using the XML
mapper utility, you specify whether the transformation is for an insert or delete
delta packet.)

• The number of update errors that can be tolerated before the update operation is
aborted. If fewer than the specified number of records can’t be inserted or deleted,
ApplyUpdates returns the number of actual failures. If more than the specified
number of records can’t be inserted or deleted, the entire update operation is
rolled back, and no update is performed.
The following call transforms the XML document Customers.xml into a delta packet
and applies all updates regardless of the number of errors:
StringList1.LoadFromFile('Customers.xml');
nErrors := ApplyUpdates(StringList1.Text, 'CustXMLToInsert.xtr', -1);
32-12
Developer’ s Guide
Writing Internet applications
Part
III
Part III
Writing Internet applications
The chapters in “Writing Internet applications” present concepts and skills necessary
for building applications that are distributed over the Internet. The components
described in this section are not available in all editions of Delphi.

Creating Internet server applications
33-1
Chapter
33
Chapter33
Creating Internet server applications
Web server applications extend the functionality and capability of existing Web
servers. A Web server application receives HTTP request messages from the Web
server, performs any actions requested in those messages, and formulates responses
that it passes back to the Web server. Many operations that you can perform with an

ordinary application can be incorporated into a Web server application.
The IDE provides two different architectures for developing Web server applications:
Web Broker and WebSnap. Although these two architectures are different, WebSnap
and Web Broker have many common elements. The WebSnap architecture acts as a
superset of Web Broker. It provides additional components and new features like the
Preview tab, which allows the content of a page to be displayed without the
developer having to run the application. Applications developed with WebSnap can
include Web Broker components, whereas applications developed with Web Broker
cannot include WebSnap components.
This chapter describes the features of the Web Broker and WebSnap technologies and
provides general information on Internet-based client/server applications.
About Web Broker and WebSnap
Part of the function of any application is to make data accessible to the user. In a
standard application you accomplish this by creating traditional front end elements,
like dialogs and scrolling windows. Developers can specify the exact layout of these
objects using familiar form design tools. Web server applications must be designed
differently, however. All information passed to users must be in the form of HTML
pages which are transferred through HTTP. Pages are generally interpreted on the
client machine by a Web browser application, which displays the pages in a form
appropriate for the user's particular system in its present state.
33-2
Developer’ s Guide
About Web Broker and WebSnap
The first step in building a Web server application is choosing which architecture you
want to use, Web Broker or WebSnap. Both approaches provide many of the same
features, including
• Support for CGI and Apache DSO Web server application types. These are
described in “Types of Web server applications” on page 33-6.
• Multithreading support so that incoming client requests are handled on separate
threads.

• Caching of Web modules for quicker responses.
• Cross-platform development. You can easily port your Web server application
between the Windows and Linux operating systems. Your source code will
compile on either platform.
Both the Web Broker and WebSnap components handle all of the mechanics of page
transfer. WebSnap uses Web Broker as its foundation, so it incorporates all of the
functionality of Web Broker’s architecture. WebSnap offers a much more powerful
set of tools for generating pages, however. Also, WebSnap applications allow you to
use server-side scripting to help generate pages at runtime. Web Broker does not
have this scripting capability. The tools offered in Web Broker are not nearly as
complete as those in WebSnap, and are much less intuitive. If you are developing a
new Web server application, WebSnap is probably a better choice of architecture than
Web Broker.
The major differences between these two approaches are outlined in the following
table:
Table 33.1 Web Broker versus WebSnap
Web Broker WebSnap
Backward compatible Although WebSnap applications can use any Web
Broker components that produce content, the Web
modules and dispatcher that contain these are new.
Only one Web module allowed in an
application.
Multiple Web modules can partition the application
into units, allowing multiple developers to work on
the same project with fewer conflicts.
Only one Web dispatcher allowed in the
application.
Multiple, special-purpose dispatchers handle
different types of requests.
Specialized components for creating

content include page producers,
InternetExpress components, and Web
Services components.
Supports all the content producers that can appear in
Web Broker applications, plus many others designed
to let you quickly build complex data-driven Web
pages.
No scripting support. Support for server-side scripting allows HTML
generation logic to be separated from the business
logic.
No built-in support for named pages. Named pages can be automatically retrieved by a
page dispatcher and addressed from server-side
scripts.
No session support. Sessions store information about an end user that is
needed for a short period of time. This can be used
for such tasks as login/logout support.
Creating Internet server applications
33-3
Terminology and standards
For more information on Web Broker, see Chapter 34, “Using Web Broker.” For more
information on WebSnap, see Chapter 35, “Creating Web Server applications using
WebSnap.”
Terminology and standards
Many of the protocols that control activity on the Internet are defined in Request for
Comment (RFC) documents that are created, updated, and maintained by the
Internet Engineering Task Force (IETF), the protocol engineering and development
arm of the Internet. There are several important RFCs that you will find useful when
writing Internet applications:
• RFC822, “Standard for the format of ARPA Internet text messages,” describes the
structure and content of message headers.

• RFC1521, “MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms
for Specifying and Describing the Format of Internet Message Bodies,” describes
the method used to encapsulate and transport multipart and multiformat
messages.
• RFC1945, “Hypertext Transfer Protocol — HTTP/1.0,” describes a transfer
mechanism used to distribute collaborative hypermedia documents.
The IETF maintains a library of the RFCs on their Web site, www.ietf.cnri.reston.va.us
Parts of a Uniform Resource Locator
The Uniform Resource Locator (URL) is a complete description of the location of a
resource that is available over the net. It is composed of several parts that may be
accessed by an application. These parts are illustrated in Figure 33.1:
Figure 33.1 Parts of a Uniform Resource Locator
The first portion (not technically part of the URL) identifies the protocol (http). This
portion can specify other protocols such as https (secure http), ftp, and so on.
Every request must be explicitly handled,
using either an action item or an auto-
dispatching component.
Dispatch components automatically respond to a
variety of requests.
Only a few specialized components
provide previews of the content they
produce. Most development is not visual.
WebSnaplets you build Web pages more visually and
view the results at design time. Previews are
available for all components.
Table 33.1 Web Broker versus WebSnap (continued)
Web Broker WebSnap
Host ScriptName PathInfo Query
Query Field Query Field
/>33-4

Developer’ s Guide
Terminology and standards
The Host portion identifies the machine that runs the Web server and Web server
application. Although it is not shown in the preceding picture, this portion can
override the port that receives messages. Usually, there is no need to specify a port,
because the port number is implied by the protocol.
The ScriptName portion specifies the name of the Web server application. This is the
application to which the Web server passes messages.
Following the script name is the pathinfo. This identifies the destination of the
message within the Web server application. Path info values may refer to directories
on the host machine, the names of components that respond to specific messages, or
any other mechanism the Web server application uses to divide the processing of
incoming messages.
The Query portion contains a set a named values. These values and their names are
defined by the Web server application.
URI vs. URL
The URL is a subset of the Uniform Resource Identifier (URI) defined in the HTTP
standard, RFC1945. Web server applications frequently produce content from many
sources where the final result does not reside in a particular location, but is created as
necessary. URIs can describe resources that are not location-specific.
HTTP request header information
HTTP request messages contain many headers that describe information about the
client, the target of the request, the way the request should be handled, and any
content sent with the request. Each header is identified by a name, such as “Host”
followed by a string value. For example, consider the following HTTP request:
GET /art/gallery.dll/animals?animal=dog&color=black HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.0b4Gold (WinNT; I)
Host: www.TSite.com:1024
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

The first line identifies the request as a GET. A GET request message asks the Web
server application to return the content associated with the URI that follows the word
GET (in this case /art/gallery.dll/animals?animal=doc&color=black). The last part
of the first line indicates that the client is using the HTTP 1.0 standard.
The second line is the Connection header, and indicates that the connection should
not be closed once the request is serviced. The third line is the User-Agent header,
and provides information about the program generating the request. The next line is
the Host header, and provides the Host name and port on the server that is contacted
to form the connection. The final line is the Accept header, which lists the media
types the client can accept as valid responses.
Creating Internet server applications
33-5
HTTP server activity
HTTP server activity
The client/server nature of Web browsers is deceptively simple. To most users,
retrieving information on the World Wide Web is a simple procedure: click on a link,
and the information appears on the screen. More knowledgeable users have some
understanding of the nature of HTML syntax and the client/server nature of the
protocols used. This is usually sufficient for the production of simple, page-oriented
Web site content. Authors of more complex Web pages have a wide variety of
options to automate the collection and presentation of information using HTML.
Before building a Web server application, it is useful to understand how the client
issues a request and how the server responds to client requests.
Composing client requests
When an HTML hypertext link is selected (or the user otherwise specifies a URL), the
browser collects information about the protocol, the specified domain, the path to the
information, the date and time, the operating environment, the browser itself, and
other content information. It then composes a request.
For example, to display a page of images based on criteria selected by clicking
buttons on a form, the client might construct this URL:

/>which specifies an HTTP server in the www.TSite.com domain. The client contacts
www.TSite.com, connects to the HTTP server, and passes it a request. The request
might look something like this:
GET /art/gallery.dll/animals?animal=dog&color=black HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.0b4Gold (WinNT; I)
Host: www.TSite.com:1024
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Serving client requests
The Web server receives a client request and can perform any number of actions,
based on its configuration. If the server is configured to recognize the /gallery.dll
portion of the request as a program, it passes information about the request to that
program. The way information about the request is passed to the program depends
on the type of Web server application:
• If the program is a Common Gateway Interface (CGI) program, the server passes
the information contained in the request directly to the CGI program. The server
waits while the program executes. When the CGI program exits, it passes the
content directly back to the server.
33-6
Developer’ s Guide
Types of Web server applications
• If the program is a dynamic-link library (DLL), the server loads the DLL (if
necessary) and passes the information contained in the request to the DLL as a
structure. The server waits while the program executes. When the DLL exits, it
passes the content directly back to the server.
In all cases, the program acts on the request of and performs actions specified by the
programmer: accessing databases, doing simple table lookups or calculations,
constructing or selecting HTML documents, and so on.
Responding to client requests
When a Web server application finishes with a client request, it constructs a page of

HTML code or other MIME content, and passes it back (via the server) to the client
for display. The way the response is sent may differ based on the type of program.
When a DLL finishes, it passes the HTML page and any response information
directly back to the server, which passes them back to the client. Creating a Web
server application as a DLL reduces system load and resource use by reducing the
number of processes and disk accesses necessary to service an individual request.
Types of Web server applications
Whether you use Web Broker or WebSnap, you can create five standard types of Web
server applications. In addition, you can create a Web Application Debugger
executable, which integrates the Web server into your application so that you can
debug your application logic. The Web Application Debugger executable is intended
only for debugging. When you deploy your application, you should migrate to one of
the other five types.
ISAPI and NSAPI
An ISAPI or NSAPI Web server application is a DLL that is loaded by the Web server.
Client request information is passed to the DLL as a structure and evaluated by the
ISAPI/NSAPI application, which creates appropriate request and response objects.
Each request message is automatically handled in a separate execution thread.
CGI stand-alone
A CGI stand-alone Web server application is a console application that receives client
request information on standard input and passes the results back to the server on
standard output. This data is evaluated by the CGI application, which creates
appropriate request and response objects. Each request message is handled by a
separate instance of the application.
Creating Internet server applications
33-7
Types of Web server applications
Apache
An Apache Web server application is a DLL that is loaded by the Web server. Client
request information is passed to the DLL as a structure and evaluated by the Apache

Web server application, which creates appropriate request and response objects.
Each request message is automatically handled in a separate execution thread. You
can build your Web server applications using Apache 1 or 2 as your target type.
When you deploy your Apache Web server application, you will need to specify
some application-specific information in the Apache configuration files. For example,
in Apache 1 projects the default module name is the project name with _module
appended to the end. For example, a project named Project1 would have
Project1_module as its module name. Similarly, the default content type is the project
name with -content appended, and the default handler type is the project name with-
handler appended.
These definitions can be changed in the project (.dpr) file when necessary. For
example, when you create your project a default module name is stored in the project
file. Here is a common example:
exports
apache_module name ’Project1_module’;
Note
When you rename the project during the save process, that name isn’t changed
automatically. Whenever you rename your project, you must change the module
name in your project file to match your project name. The content and handler
definitions should change automatically once the module name is changed.
For information on using module, content, and handler definitions in your Apache
configuration files, see the documentation on the Apache Web site httpd.apache.org.
Web App Debugger
The server types mentioned above have their advantages and disadvantages for
production environments, but none of them is well-suited for debugging. Deploying
your application and configuring the debugger can make Web server application
debugging far more tedious than debugging other application types.
Fortunately, Web server application debugging doesn’t need to be that complicated.
The IDE includes a Web App Debugger which makes debugging simple. The Web
App Debugger acts like a Web server on your development machine. If you build

your Web server application as a Web App Debugger executable, deployment
happens automatically during the build process. To debug your application, start it
using Run|Run. Next, select Tools|Web App Debugger, click the default URL and
select your application in the Web browser which appears. Your application will
launch in the browser window, and you can use the IDE to set breakpoints and
obtain debugging information.