Automating Perl Database Applications
A number of options are available for Perl developers who want to reduce the amount of work and tedium involved in writing Perl CGI scripts that interact with a database server. Some of these alternatives include CGI::Application and Class::DBI with the Template toolkit. However, these solutions may not be appropriate for every situation. Web sites hosted at an ISP may not include these Perl modules or allow customers to install these modules within the Perl directory hierarchy. These solutions still do require some programming and therefore may not be suitable for entry-level developers.
This article describes how Perl is used to generate Perl CGI code using the multi-platform CGIScripter application. The resulting output code automates SQL table creation commands (in this example, for a MySQL database), HTML pages and Perl code. Web security issues, data validation and image handling functionality are incorporated into the resulting Perl code. By automating the development of Perl CGI scripts, even entry-level developers can create CGI scripts that contain most of the commonly requested features in a short period of time--without manually writing any code.
This article does not cover the installation or configuration of Perl, Apache, MySQL or DBI/DBD software on a Linux server. You can find information on these topics in a variety of places on the Web, within several well written books and in the documentation included with each Perl module.
The CGIScripter graphical interface has been implemented in the Revolution development environment from Runtime Revolution Ltd. The graphical interface allows the user to enter/change information, load/save files and provides data validation on a field by field basis. The heavy lifting, however, is accomplished by a Perl program that reads configuration files written by the graphical interface and then generates the Perl, HTML, database table creation SQL and instructions files (see Figure 1).
Revolution is based on ideas originally incorporated within Apple Computer´s HyperCard in 1987. Revolution, though, is a built-from-scratch implementation that contains no Apple code. The Revolution IDE not only runs on Linux, it also compiles standalone graphical applications for over a dozen different operating systems. Many modern programming language features found in Java and Perl, such as object orientation, runtime compilation, automatic memory management and garbage collection, were implemented within Apple´s HyperTalk. Runtime Revolution has named its development language Transcript, but it is HyperTalk-compatible and contains a significant number of language enhancements. The development environment uses an object-oriented message passing architecture in which the code for an object actually is stored within the object being programmed. This means that if I want to add functionality to a button on the GUI, I generally place that code within the button itself. Applications developed in Revolution look and work identically across each operating system (see Figures 2, 3 and 4).
Four folder tabs appear across the top of the CGIScripter window; we concentrate on updating them first. Update the default contents of each field on the General and Other folder tabs as shown in Figures 5 and 6. We don't need to update any fields on the Oracle folder tab.
Click on the CGI tab and three more tabs become visible under the first group of folder tabs (see Figure 7). These three tabs enable you to enter parameters specific to the Web Site, each Web form and the fields located on each Web form. The Web Server menu defaults to UNIX, which we do not need to change, although code also can be generated for Windows IIS Web servers.
The Max Submit Size determines the total number of bytes that can be submitted to all fields of the form at one time. This parameter is directly translated into the POST_MAX parameter used by the CGI.pm module. Limiting the amount of data accepted by the Web form helps prevent one type of denial of service attack that can be launched against a web server. For this example, the default value of 10,000 bytes has been increased to 100,000 bytes, because we are going to allow the uploading of images to the database.
The Web site URL is used to construct form submission URLs and documentation within the generated scripts. For example purposes, we can use the IP address of the Web server being used here for testing, which is 10.1.0.25. This value then can be changed to an actual production Web server URL and the scripts regenerated after testing has been completed locally. Because the resulting output code is re-created accurately by CGIScripter, we don't have to worry about making a typo while making manual changes to the scripts.
- High-Availability Storage with HA-LVM
- DNSMasq, the Pint-Sized Super Dæmon!
- Localhost DNS Cache
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- Linux for Astronomers
- Days Between Dates: the Counting
- You're the Boss with UBOS
- The Usability of GNOME
- Multitenant Sites
- PostgreSQL, the NoSQL Database