Programming | Advanced 10th Chapter ASP and client data
Discuss client data in an ASP monograph, is this inconsistent with server-side ASP programming? This is not the case because we have not yet encountered an ASP programmer who is only engaged in server-side programming. Although ASP is a server-side technology, it is conceivable that programmers cannot only use ASP for programming. Web developers who are engaged in ASP programming still need to interact with the client data.
As a result, building an application around an ASP must take into account the entire application, which also means that the client must be considered. To get a good, fast-responding application, you need to use client data well.
This chapter discusses how to use data on the client. Particular emphasis will be on:
· Remote Data Service (services,rds), how to transfer data to clients, and clients to receive data.
· How to bind an ADO recordset to an HTML control.
· How to provide data using user-defined components.
· How to update the client data and feed it back to the server.
· How to get an image from a database and display it in a Web page.
· How to create a Web page that is based on a table.
The coverage is broad and there are many different ways to achieve the same results, but in practice it is not particularly difficult to achieve.
10.1 Disconnected recordsets
The first thing you need to know is the concept of disconnected data. So far, in the process of studying ADO, you've learned how to get recordsets, and how to modify the data in those recordsets. In retrospect, we open a recordset, make some changes to the data, and then close the Recordset, which is always connected to the server during the recordset operation. This is quite obvious, but don't forget that the web is essentially stateless. If you want to use client data, how do you always keep a connection to the server? Quite simply, this is not possible, which is why the concept of a disconnected recordset is defined.
A disconnected recordset is just a normal recordset, but disconnects from the server, becomes an orphaned object, and can perform updates, additions, and deletions like a regular recordset. However, these changes occur only within the recordset and are not fed back to the server because the recordset is no longer connected to the server. This is not a disadvantage because you can re-establish a connection with the server, and the server can update any modifications. Even if server-side data has changed, ADO still has a way for users to discover these changes in time so that users can decide which data is correct. This is known as conflict handling (conflict resolution).
A disconnected recordset enables us to transfer a recordset with full functionality between components, including between the server and the customer. Later in this chapter, you will explore how to create a disconnected recordset within a component. But this is not an overly detailed study, since chapters 13th through 18th of this book have covered this section, and here is a simple introduction to how components interact with remote Data services.
10.2 Remote Data Services
Remote Data Service (Services,rds) is a general term for a series of services that allow us to process client data. There is no need to worry about this now, because RDS itself is part of ADO and will only be used if you need to transfer and use client data. RDS is actually composed of several components. Figure 10-1 illustrates these components and how they work together.
Figure 10-1 Component composition of RDS
There seems to be a lot of components, but not all components are used in each case, and there are actually some that are not part of RDS. Here, however, all the possible components are placed on the diagram for viewing when needed. Figure 10-1 is divided into two parts, because using client data requires some way to transfer data to the client, and once the data arrives at the client, some methods of managing the data are needed. Let's start with the server side first.
10.2.1 RDS Server Component
Although RDS is used to transfer and access client data, it does have some server-based components. This is required because certain ways of transferring data to the client are necessary. So there is a series of server components that can access data and allow data to be sent to the client. We refer to the actual data transfer as a dispatch (Marshal).
The top end of the server-side component diagram is the data store, accessed by the OLE DB provider. It is not part of RDS, but it means that with the corresponding OLE DB provider, any data can be used on the client via RDS. There are two options for how to handle data on a server:
· The Data Factory (DataFactory) is the default server-side component for accessing the data store. It is installed on your computer as part of a server-side RDS component, and it handles data sent to and from the client, in addition to the data stored in the data store.
· Custom components are just a common COM component that provides a data transfer method. You can use custom components when the Data Factory does not provide the functionality that you want. This chapter presents a simple example of a component, and there is a more complex example later in this book.
The Web server uses these two components as an interface between client and server data.
10.2.2 RDS Customer Component
Starting at the bottom of the DataSpace object, the client works in conjunction with a data factory or custom object as part of the client. The DataSpace object is a proxy object that communicates with the server and is also a channel for data transmission (or, generally, a dispatch). The DataSpace object is a COM object created in either the client-side scripting language or the <OBJECT> tag in the HTML language. Examples of this are shown later in this chapter.
The DataSpace object above is the data source object (DataSource Object,dso), which is responsible for storing client data. A data source object contains an ADO data recordset that manages data together with the customer data cache. Customer data caching is simply a client cursor service that manages client data. The data source object is also a COM object, similar to the DataSpace object, and can be created either through client script or by using the <OBJECT> tag in the HTML language. Also, some examples of this are presented later in this chapter.
Above the data source object is the data binding manager, which is the task of establishing a connection between an HTML control and a data source object. This is what we know about bindings that can be implemented by setting the DATASRC and DATAFLD properties of some HTML controls. These are discussed below and demonstrate how to easily use the data in a browser.
10.2.3 browsers that support RDS
To know that RDS is Microsoft's technology, it can only work on Microsoft's browsers. In fact, RDS is fully supported only in IE 4.0 or later browsers.
When writing applications that depend on RDS, you need to be aware that the RDS version of the customer accessing the application may differ from the server side. For example, the RDS 1.5 version is in IE 4 and the RDS 6 version is in IE 5, Office 2000, and Visual Studio 2.0. There are two ways to handle this compatibility issue:
· Ensure that all users have upgraded to the latest version of RDS. If the customer is running Windows 2000, the latest version of RDS is already running. Otherwise, you can download it from the URL www.microsoft.com/data. The RDS 2.5 version is currently the latest release with Windows 20,001, and is a stand-alone package to download.
· Specifies the schema of the Data Factory when connecting to a data source. This allows you to specify which version of the RDS component to use, followed by an example of this.
10.2.4 Data Source objects
A data source object is a client object that stores and manages client data. Because this is the easiest way to use RDS, look at these objects first.
There are several different data source objects, each for different types of data:
· Tabular Data Control (tabular Data control,tdc), which is used to process text files in tabular form or in separate forms.
· The RDS data control, which connects to the OLE DB data store, to specify which data store to connect to, and what data to return.
· Java Database Connector, a Java applet that connects to a data store through a Java database control (Java DB CONTROL,JDBC). We do not want to discuss JDBC here because it does not provide functionality that other controls cannot implement.
· Microsoft's HTML (MSHTML) Data source object uses HTML to tag the data and takes it as a data source.
· XML data source objects use XML data for structured or arbitrary-structured XML.
Choosing which data source object depends on what you want to do and where the data comes from. A tabular Data Control (TDC) may be appropriate if you need to provide a small amount of data to the customer and do not allow the user to modify the data. This data source is a text file and does not require any databases, so it is easier to edit. The RDS data control is most appropriate for situations where data is removed from the database and may need to be updated. For many new data sources, you'll find that you need to use an XML data control at this point. This actually depends on the type of Web application you are using, as well as the functionality required by the user.
We'll introduce these data controls in turn, and once we know how to use them to transfer data to the client, we'll explain how to use that data.
1. Tabular Data Control
Tabular data controls (tabular data control,tdc) are the simplest data source objects, primarily for a small number of read-only data, especially those that do not change or are rarely modified, and do not need to be updated from the client. For example, a tabular data control can provide a list of menu items or links within a Web page.
You can create a tabular data control by using the <OBJECT> tag in your HTML code. Parameter Dataurl can specify the package
[1] [2] [3] Next page
