http://www.devarticles.com/c/a/ASP/XDO-An-XML-Engine-Class-for-Classic-ASP/1/
In this article, Carlos explains how to integrate XML into your applications using ASP.
Summary:
This article details an approach to integrating XML into database-driven applications or websites using classic ASP. The goal of this approach is to encapsulate database interactions into a reusable object that will handle data retrieval, including simple hierarchical data, by leveraging ADO and XML.
The result is the beginning of a framework that allows the separation of the data, business and data-access layers. This, in turn, facilitates the implementation of distributed application architectures.
Introduction:
By now most web developers have heard of XML and of its value to the web and distributed computing. In classic ASP, Microsoft has provided the pieces for developers to take advantage of XML in different ways. This article suggests a framework for making database driven ASP applications using only XML. It achieves this goal by encapsulating data retrieval into a VBScript class.
Prerequisites:
This article requires that the reader be familiar with the following:
• VBScript Classes and the advantages of OO design,
• XML, XSL, their use in ASP, and advantages, and
• ADO and its use in ASP, particularly persistence of Recordsets and Data-Shaping.
Overview:
Many articles have been written demonstrating object-oriented (OO) and XML features available in ASP including:
1. Creating a Datagrid Class in classic ASP - 2-Dimensional Arrays by Brian O'Connell
2. A Generic GetRows VBScript Class
3. Using Classes in ASP (OOP in ASP/VBScript - Part #2) by Marcus Brinkhoff
4. Converting Hierarchical Recordsets Into XML By Richard Chisholm
5. Increasing ConvertRStoXML() Performance By David O'Neill
6. An ASP Class for XML Data Transfer by Seth Juarez
These articles adequately explain the benefits of OO design and of XML use in ASP. The data access objects even show how OO design can help manage creation and destruction of precious ADO connection objects.
However, they still either bind the interface to the data (as in the DataGrid article) or they still looped through recordsets or arrays to create their XML. It was not until Transforming ADO Recordsets to XML with XSLT that we begin to see that we can piece the tools available in the classic ASP platform to create a reusable, extensible, and flexible framework with XML as the foundation.
XDO seeks to implement such a framework and makes it possible to retrieve XML data from the database. This allows the developer to have SQL Server-like XML capabilities with any database that can be accessed with ADO via OLEDB.
Design:
Current architectures for distributed applications recommend object models that follow object factory (or engine – collection – class) design patterns. XDO emulates this design pattern for the data access tier in n-tier architectures. Business rules, captured as function libraries or as other classes, can create an instance of the XDO object and return XML that matches the rule coded within the called function or object method. The resulting XML is then transformed with XSLT to render the user interface (See figure 1).
XDO is a custom data access object that encapsulates the functionality of MSADO objects. In a “real-world” implementation, no ASP page interfaces with ADO objects directly. Instead, ASP pages create instances of the XDO object, which in turn interacts with ADO. Instances of ADO Connections and Recordsets are managed by XDO. Furthermore, Business objects can encapsulate the instantiation of XDO objects.
Examples include a Customer XML Engine or a Catalog XML Engine. This adds another layer of abstraction in the object model thereby separating business rules from the presentation (display) code.
XDO is a custom data access object that encapsulates the functionality of MSADO objects. In a “real-world” implementation, no ASP page interfaces with ADO objects directly. Instead, ASP pages create instances of the XDO object, which in turn interacts with ADO. Instances of ADO Connections and Recordsets are managed by XDO. Furthermore, Business objects can encapsulate the instantiation of XDO objects.
Examples include a Customer XML Engine or a Catalog XML Engine. This adds another layer of abstraction in the object model thereby separating business rules from the presentation (display) code.
The required components of this framework are:
• IIS 4.0+ running VBScript 5.0+,
• MSXML parser 3.0+, and
• Microsoft’s ADO 2.0+
The main object used in the architecture is the XDO object. This object is a stateless component that returns an XML document object model (DOM’s) of data in the database. These XML DOMs are stateful representations of customers, employees, orders, and products. The XML DOM represents the data describing the object.
Implementation:
The sample code provided demonstrates the use of the XDO framework. It uses the Northwind Access database for the data-source but will work for and ADO accessible database. The default.asp page displays a drop-down list of customers by default and allows the user to click buttons to view either the selected customer’s details or their 3 most recent orders.
Execution of the typical ASP page in this framework involves adding the class references to the page through #include directives, validating the request, creating an instance of the business object engine, CustomerXMLEngine, calling the appropriate business object method, transforming the data with appropriate XSL, and returning the resulting HTML interface.
The demo is made up of:
• The default.asp page, that controls which business object method is called,
• The Class.CustomerXMLEngine.asp, that houses the business model’s logic, and
• XSL stylesheets, that are used to transform the returned XML. The default.asp determines which view is displayed based on the arguments submitted.
• XDO, with serves as the
Default.asp
This design allows the same ASP page to render 3 different interfaces (Figure 2). Looking at the code, one can see that the implementation code is reduced to a few lines of code.
The default.asp page interacts with the business object using the “new” statement, returning an instance of the business object.
'/// CREATE AN INSTANCE OF THE CustomerXMLEngine
dim engCustomer : set engCustomer = new CustomerXMLEngine
Data is retrieved from the CustomerXMLEngine object by calling its methods. The example below returns a simple list of customers (ID and CompanyName) and is transformed into a drop-down list using xsl.
'/// GET A STYLE SHEET
dim objXSL
set objXSL = loadStyleSheet("xsl/customerSimpleList.xsl")
'/// CALL THE getSimpleCustomerList AND TRANSFORM TO GET DROPDOWN LIST
dim sCustomerDropDown
sCustomerDropDown = engCustomer.getSimpleCustomerList().transformNode(objXSL)
Class.CustomerXMLEngine.asp
The CustomerXMLEngine contains the rules that define what data to retrieve from the database and applying any rules (like applying a customer discount) at that time. Each method has a SQL statement that determines the resulting XML. On initialization, the business object creates a single instance of the XDO object and sets the connection string.
'INITIALIZE OBJECT
Private Sub Class_Initialize()
m_sObjectTag = "Customer"
set m_oXDO = new CXDO
m_oXDO.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" _
& Server.MapPath(".") & "\database\NWIND.mdb;"
End Sub
This instance of the XDO object is used in each method to execute their SQL and returns an XML dataset.
Public Function getCustomerList()
dim sSQL : sSQL = "SELECT * FROM Customers"
set getCustomerList = getDOM(sSQL)
End Function
…
'GET XML DOM FOR PROVIDED SQL
Private Function getDOM(SQL)
set getDOM = m_oXDO.getXMLDOM(m_sObjectTag, SQL)
End Function
The XML is returned as a DOM object to facilitate XSL transformation.
XDO
At the heart of this framework lies the XDO object. It is designed to convert Recordsets, including hierarchical (or shaped) Recordsets, into element-based xml. I chose element-based xml to facilitate the creation of XSL templates.
An XDO instance’s lifespan begins with the creation of an ADO Connection. This Connection is available to the XDO object until the terminate method is called. The primary method is getXML, which is exposed as a public method if only the xml string is needed. A secondary public function is getXMLDOM.
This method calls getXML, loads the xml string into an XML DOM object, and returns the DOM instance.
The getXML method, when called, executes the loadData() method. This calls openConnection() and the MSDataShape provider is set if the a shaped SQL statement is provided.
Private Sub openConnection()
dim sConn : sConn = m_sConn
if (Instr(1, UCase(m_sSQL), "SHAPE") = 1) then
if (m_Connection.State = adStateOpen) then m_Connection.Close()
m_Connection.Provider = "MSDataShape"
sConn = Replace(sConn, "Provider", "Data Provider")
end if
if (m_Connection.State <> adStateOpen) then m_Connection.Open(sConn)
End Sub
Next, loadData() executes the query and the Recordset is persisted as XML using the Recordset’s Save() method. At this point, the XML format is in the Microsoft ADO-specific markup. I have written a generic XSL template that transforms shaped and non-shaped Recordsets from the Microsoft markup to element-based markup. This XSL is coded as a string, instead of an external XSL file, to aid XDO’s portability. After the transformation, the resulting XML string is returned.
Though the demo is implemented as VBScript classes, this model is easily translated to COM or other platforms. I have used VBScript classes because some of my clients and my web-host do not support custom COM development.
XDO facilitates the creation of XSL templates by rendering element-based (also called tag-based) XML. Element-based XML, unlike attribute-based XML (like that of ADO), uses a simpler XSL syntax. This makes creation or updating of XSL templates, which render HTML, much easier. Also, the XML document object model (or DOM) still allows searching and sorting of data and requires less overhead than an ADO Recordsets.
Persistence to the database is not mentioned in this model. However, there are a number of ways to address this. One might extend the XDO object to support persistence to the database. Another method might be to create a separate database persistence object to handle this function. Either way this function would also be encapsulated by the business object and not directly called by the ASP page.
This framework separates web applications into different tiers, a data tier, a business rules tier, and the presentation tier. This delegation of duties is clearly delineated with XDO, ADO, and the database making up the data tier, the CustomerXMLEngine in the business rules tier, and XML, XSL and HTML in the presentation tier.
Extending a business object is as simple as adding the new method and altering the default page to process the inputs and render the appropriate interface with XSL. Adding a new Business object, like an EmployeeXMLEngine, is easy to create with the CustomerXMLEngine as a template. The result is a flexible architecture that is easy to expand and maintain.
Further Reading:
• Creating a Datagrid Class in classic ASP - 2-Dimensional Arrays by Brian O'Connell
• A Generic GetRows VBScript Class
• Using Classes in ASP (OOP in ASP/VBScript - Part #2) by Marcus Brinkhoff
• Converting Hierarchical Recordsets Into XML By Richard Chisholm
• Increasing ConvertRStoXML() Performance By David O'Neill
• An ASP Class for XML Data Transfer by Seth Juarez
Posted by 홍반장
