Review: It's meant to make CGI database scripts easier to manage. Good idea, but CGI Scripter's UI is funky and the software's too rigid to be useful.
CGI Scripter, from .com Solutions, Inc., promises to make CGI database scripts easier to manage, providing ready-to-run Web pages and scripts that allow inserts, updates, deletes, and queries into several database formats. The software works on multiple operating systems including Windows, Linux, and Mac OS X. Good idea, right?
If you find yourself in a multi-platform, multi-database Web development role, this software might be useful for you. For the large majority of Web developers, however, the software has too many rough edges and is too rigid to be truly worth the effort.
First, a short introduction to CGI. Web browsers graphically parse tags stored on a Web server. The user doesn't have a constant connection to the server, nor can the server run programs on the client machine. If your applications need complex interaction, this presents an issue; the user can't, for instance, interact with a database. The earliest solution for this problem was a program layer on the Web server called CGI, the Common Gateway Interface. Using CGI, a Web developer writes server-side scripts, and the result of a script is returned to the user's Web browser. Although newer Web servers, such as Microsoft IIS and Apache, have far more sophisticated user and database interaction capabilities, CGI is still in common use. CGI Scripter uses this CGI layer exclusively.
The scripts CGI Scripter creates use the Perl scripting language, a multi-platform scripting language widely used on Unix-flavored servers. While Perl isn't the only language you can use with CGI programming (you can use any, in fact), it is the only language CGI Scripter supports.
I downloaded the software for the Linux and Windows operating systems from .com Solution's Web site. The software download contains only a single file, the program itself. For the installation process I also had to download the readme.txt file from the same Web site. The documentation showing how to use the pages and scripts created by the program is also online, but is located as marketing documentation under the Files area.
You may have more work to do before you get started. In addition to the program, you need to install Perl and its DBI and DBD-ODBC drivers (at a minimum). The process for this installation is located at the ActiveState Perl Web site. If you're using a Windows platform, the Perl Package Manager will perform these installations for you from a single command (install DBI). If you're using Linux, you can use the CPAN interface to do much the same thing.
The rest of the setup process depends on your database. If you're using Oracle, you only need that Perl DBD interface installed. With other databases, such as Microsoft Access or SQL
Server, you need the ODBC Perl DBD and an ODBC connection with a name as defined in the form1_instructions1.txt file the program generates. This file is not generated until the scripts are created.
I tested CGI Scripter on four environments, using Windows and Linux operating systems. I began by running the program on a Windows XP to SQL Server test box. The opening panel of the product is an information and advertisement screen. I skipped over this to the General tab as shown in Figure 1.
Figure 1: General Tab
The tab shown in Figure 1 displays the primary issue I have with CGI Scripter: the user interface isn't arranged in a logical fashion. For instance, the General tab contains script
documentation inserts (the Customer: text box), the Perl program binary location, the output directory, and the database platform, which the program calls a "Version." These fields aren't all related to one another, and General is far too unspecific a term to have real meaning. An example of the discontinuity is that I had to manually enter the table name on this tab, but the database is specified on subsequent tabs.
Nor is that the only user interface frustration. CGI Scripter allows only mouse-based navigation to the output directory (where both the scripts and Web pages are created) but you have to type the path to the Perl binaries. Modern UI design normally dictates a system or database query to automatically fill out this information where possible, and both an editable selection area (with intelligent automatic entry) and a navigation button for each text box.
Some text boxes and selection areas have context-sensitive help; others do not. A full explanation of these fields is not available until you generate the final scripts. I'm not certain of the logic behind generating the help file after you've already used the product.
The next tab, labeled Oracle, is there whether or not I selected an Oracle database on the first tab. The default settings on this panel assume I'll create a new database for the scripts, so I would have to provide table and index spaces and specify the file locations for those constructs each time I use the software. Since I'm using an existing database, I checked the boxes marked "Use existing." (This also violates modern UI design. Programs should
always assume the most common options, and creating a new database via script isn't a common occurrence in most Web applications.)
Figure 2: Oracle Tab
On the tab marked Other — I assume this to mean other databases — I entered the host name, the name of the database, a port number, and the login credentials. Some platforms (such as SQL Server or Microsoft Access) don't always need all this information. A single panel with conditional database information would be more appropriate than spreading the entries over three tabs.
Another issue on this panel involves the login credentials. The password is plainly displayed, and isn't confirmed or checked against the database. I realize that the password might be stored in plain text in script files, but it's still a bad idea to display it during design. All operating system GUI calls include a password function, which obfuscates the text as it's typed, so I'm not sure why this is left open to view.
Figure 3: Other Tab
The final tab, CGI, deals with the forms and fields that are created in the final Web pages. This part of the program is the best thought-out. The Generate CGI button (which should be named "General HTML pages and Perl scripts" or just "Generate," though maybe I'm overcritical by now) creates 15 files. One of these, as I mentioned earlier, is the instruction file for the previous steps. It seems odd that the instructions on how to create
files are created when you generate the files.
Once the program generated the scripts, I had to move them into the proper scripting and Web server locations. If the company expects the audience for this program to be a novice (experts would create their own scripts, or use ASP.NET or PHP), this might prove
a challenge.
The scripts are well-formed, but quite wordy; the query script alone exceeded 270 lines. I was able to create the same result set in a 15-line Perl script for the query function, although my script had minimal error correction and formatting.
On the Windows XP to SQL Server system I tested, the scripts ran, but the Web pages produced no output. I checked the basics, and could connect to a database using the Perl version I had installed. I contacted .com Solutions, who responded immediately. They suggested that I disable my firewall, which did not correct the problem. I discontinued my tests on that platform since there were too many variables for me to change, such as MDAC level and
ODBC libraries.
The other platforms I tested worked successfully. The Perl DBI is notoriously slow for large data sets, but the software is more suited for small transactions anyway. Even small transactions were noticeably slow for the Microsoft Access connection. I perused the .com Solutions Web site, and found indications that performance was sometimes an issue for Perl and Access.
The software does perform as advertised: it creates Perl scripts and HTML pages for various database platforms. My issues with CGI Scripter are that the user interface is disjointed and poorly formed. There isn't a facility for editing the scripts or creating templates, Perl is the only language supported, and the HTML doesn't include a template function.
The product seems suited to multiple platform, multiple database environments where little customization is needed and light use is warranted. If you're an experienced programmer, skip the CGI layer altogether and use the PHP or ASP.NET functionality built into the more popular Web servers. They are far easier to implement and have more features, especially if you're using a single database platform. If you're new to Perl or want to use it with CGI, browse
the thousands of free scripts available on the Web to create your own methods to access databases.
Hits:
- Simple installation (just run the program)
- Consistent interface across all platforms
- Scripts are well-formed
- Easy to download a demo
Misses:
- Single scripting language
- No edit capability
- No HTML customization
- Illogical user interface
- Help file for the product is created after you use it
- No user documentation shipped with the product
