Use FDO package XML & ADO to implement communication with server data communication
Author: LeeFJ
What is FDO? I don't know if I have said this concept, anyway I think of this name: Flash Data Operator, I don't know if it is in the Flash V2 component. FDO is a set of classes, and the cooperation with this group and the server can communicate and server communication in Flash, this is my idea. However, this idea source Zou Zou is a friend on the Flash8 Forum. He has a thing called me to change, huh, oh, the ability is limited, I can't see the dazzling code, huh, so I think I want to be a FDO convenience. To process server data.
FDO The first question is security. Do I want to assemble SQL on the client? That is very unrealistic, it seems too unsafe, it is obvious. So you should use a secret number and an external parameter. For example, a secret number: show me the MONEY
Can you correspond to a SQL statement: SELECT * from Money where user = '?, This way is a bit similar to the SQL writing in the preparedstatement in Java,? You can use parameters. Oh, this is an idea I am more naive. One table (COMMAND) can be created in the server (can be implemented with an array), so when the client requests, the SQL can be queried according to this number. Avoid malicious SQL inputs to a certain extent.
In fact, FDO is not only FDO in Flash (Client), she should include the server's FDO, I use ASP here, I use the server's FDO class to encapsulate ADO, so there is almost no need to call the ADO method as long as the FDO method is used. Or processes can be.
Then, for the first problem, the client FDO can include the following classes and one containing files in the FDO package:
· Contains files: declare the author and version information, and public functions, etc.
· Fdo.as: Define the FDO class in this file to complete the data interaction with the server.
· Command.as: It is used to generate an operation command and submit to the FDO class.
· RecordSet.as: Make very easy to get data in the received XML, similar to the Recordset object in the ADO. It is designed to read only.
· Record.as: Defines the RECORD class, which is primarily input as parameter when updating and inserting data.
Here, I designed the RecordSetlei class as read-only, I don't think there is any meaning of the data to modify it, because it does not actively update the database. Its most important reason is the network delay, and any time to interact with the server needs time. When we handed the initiative of the program to Flash Player (Flash Player To wait for the server feedback, then call the Ondata OnLoad and the events such as the Ondata OnLoad), only after the Player calls the data download, Flash's continued playback is meaningful. It is very simple: if you don't give me the data, how can I go forward! So since the FDO class interacts directly with the server, it should be a callback event for FDO to rewrite these events for FDO users. The purpose of these events is to wait for data or operation (ie, interaction with the server), continue to drive Flash's playback. This is very well understood, we usually use a download process in the title, wait until the download is completed. The truth is the same, no server data, playback is very likely to be wrong, so Flash will wait until the server data arrive will give the initiative to the user (refer to the developer), and the user can rewrite the callback function. Interaction with the server usually includes four types: query, insert, update, delete. Only the query returns the data required by the user (developer), and other operations return a result of the operation. For example, several records have been updated, the insertion data is successful, or some can't predict during operation Errors, these errors should return to the Flash client so that the developer will not process, or the end user of the error to apply. These guarantee the robustness of the program.
So how to design the FDO class? My approach is the first to be two XML objects, one for sending commands to the server, one, receives data returned by the server, of course, these data, commands, and the result is XML format. Then need to maintain the FDO status, is idle, or busy. FDO should also include three events for user rewriting to drive their Flash to continue playing:
· OnLoading Event: This time enters a percentage of load as a parameter and is continuously called until the FDO is completed, just like OneterFrame, of course, the frequency of the call can be determined by the FDO designer, or the user can be used as a parameter input . The purpose of this event is to drive download progress bars and provide good interactions for end users.
• OnData event: This event is usually called when the data download is completed, and the XML data acquired from the server (THIS reference in the XML.onLoad event) is passed, which must be transmitted as this parameter during the Recordset class configuration.
• OnResult Event: Tell the development of this command to perform successfully in the execution of insertion, update, or modification.
The FDO class also requires a continuous call approach to check the download schedule, and then call the only online function in this method.
The main task of the Command class is to generate XML in a certain format, then hand it over to FDO. It is relatively simple as the Recordset class and the Record class. Wait a minute, I posted some source code.
The server's FDO class is relatively simple, mainly used in ADO and XMLDom, you can see some information on the Internet.
