How Our Message Board Works
One advantage of using Flash MX in development of a message board system is its ability to format data into a more presentable fashion than Flash 5 allowed. It also parses XML content like a demon. This system uses the ScrollPane component (a default Macromedia component that comes with Flash MX) and TextField formatting (via ActionScript) to present threaded information to viewers.
This message board uses .NET technology. It executes upon receipt of information and commands originating with the client, processes information, and returns information back to the client. It's a complicated system, but built in such a way that it can be used in a great many different applications, engaging and processing many different request types.
The following is a breakdown of the process this message board takes in terms of the backend communication that makes it work. It's quite technical in the details, and I present it so you get a better idea of how the backend is functioning. Afterward, we'll crack the .FLA open so you can see the guts of the front end itself.
The Backend Process
The first two chapters focused on using ColdFusion as the server-side language. While we have provided code in ASP.NET and Java, we haven't discussed how it was designed. One of the goals we set out with for this book was to teach how code could be reused across projects on both the client and the server. To this end, you'll see that many of the classes are used over and over again in all the projects. Because this is not a book on object-oriented application development, we only briefly cover the concepts involved.
The key piece of reusable code is called the TransactionController. This object in both Java and C# is used to field requests for work to be done. We have broken that work up into discrete transactions because that makes the most sense. In most of the projects, we have a transaction called Login or CreateUser. These are distinct pieces of work that need to be done in order. The Flash client sends a request to the server via XML over HTTP and the server responds once the transaction has completed.
In the following series of steps, we break down the basic process for you.
The client (Flash MX message board SWF) passes in an XML document that has been created in a standardized format over HTTP to the TransactionController.aspx page. This is the same basic XML format we use for all the projects in this book. Using a standardized format makes it much simpler to reuse code across projects. The code for this particular page is in the TransactionController.cs file. These files are included in the C-Sharp section on the CD-ROM.
The transaction controller passes the XML document and gets the transaction name as a string (such as GetTopics, GetThreads, CreateUser, and so forth). It takes that and the rest of the XML document and places it into a new TransInfo object.
The TransactionController instantiates a TransactionService object and passes in the TransInfo object.
The TransactionService gets the transaction name from the TransInfo object and dynamically instantiates a copy of the appropriate transaction class as an object of type object. It then casts this object to an ITransaction object. The ITransaction class is an interface that all transactions (GetTopics, GetThreads, CreateUser, and so on) implement.
The TransactionService calls the Execute method on the new transaction object. The transaction object takes the TransInfo object and uses the data within it to do its work. It then builds and returns a TransResult object to the TransactionService.
The TransactionService passes the TransResult object back to the TransactionController.
The TransactionController takes the XML out of the TransResult object and sends it back to the client (Flash MX message board).
Whew. That's a pretty in-depth explanation of the entire process, but you can see how powerful this system really is. It is set up to handle any kind of request, and it's self-moderating, meaning it can catch and handle any error it encounters along the way. Figure 3.2 is a diagram of the system flow to try to make the whole process a little easier for you to understand.
Figure 3.2 Diagram of the backend process.
If you are a C# developer, or are interested in the .cs files, feel free to open them with your favorite editor and examine the scripting. If you decide to modify any of the scripts, we have supplied a batch file (compileCSharp.bat in the chapter_3/C-Sharp folder on the CD-ROM) so that you can recompile your .dll file.
Remember, that the Flash Transactions.cs is the key to this whole system. It sits on the server ands is of a true OOP construction. It fields generic requests and works for all applications in this book. It is for .NET implementations only. You can expand its capabilities if you want. It will work the same with Access and SQL the code is exactly the same for both. A helper file determines which to use and how.
The system writes to an Access database (.MDB). This database (Figure 3.3) contains all the information necessary (user information, topics, threads, and messages) for the fully-functioning message board. The Messages table maintains a circular association in the scheme of the database. A sample .mdb (MessageBoard.mdb) is included in the Chapter 3 folder on the accompanying CD-ROM; it contains data that was created during the testing of the message board.
Figure 3.3 The Access database tables and their relationships.