|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Monday, 26 March 2001||Author: Marcelo Pham|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Printable]|
Writing Database Oriented Web-based Applications with Perl - Part IV
Marcelo wraps up his series with some tips on debugging web applications, security, and advice on programming standards.
|Page 1 of 1|
Interfacing Perl with the database (II):
19. Editing and deleting records from your application
In the last installment we made a simple script to add a new record to the contact table. We will now make a simple program to modify and delete an existing record. Please recall the sample scripts of the last installment, that is, add.html, add.cgi and add2.cgi.
Let's make the edit screen. As usual, the HTML page (edit.html ) goes first:
And the cgi scripts go after. First, edit.cgi:
And now, the last script (the one that actually updates the database) edit2.cgi:
I will leave the delete script for you as an exercise. (solution available)
This is basically what you have to do for each function of your web-based application, you can use these skeletons to build your own. Remember that you are in a high traffic environment and every single byte that you send or receive affects the whole application's performance. And also remember to implement your code based on your initial design.
Assuming that you understood the structure of the programs, let's go over a couple of very basic debugging techniques when programming web-based applications.
Syntax errors: your first attempt to find possible typos in your script is compiling the programs for syntax errors. You can achieve this by using the Perl compile option (-c). From your Linux console type: # perl -c <myscript.cgi>
And Perl will output errors and/or warnings. If everything is fine, Perl will output <myscript.cgi> syntax OK
File errors: usually you cannot execute a Perl file if it does not have permission to be read and executed (for example, when you get a "Internal Server Error" page from your browser). Make sure that your script can be read and executed (using chmod a+r <myscript.cgi> and chmod a+x <myscript.cgi>) and, if you are working from a workstation, make sure that the script was properly uploaded (in ASCII mode).
Library/Module errors: you may also get an annoying "Internal Server Error" page if you have a script that declares a library or module that does not exist. For instance:
In this case, either DBI is not installed or dbconn.lib does not exist or cannot be located under the script directory.
Database errors: to trap database operation errors, DBI returns two variables: DBI::err and DBI::errstr in order to describe the error. For example
What you can also do is include the SQL statement to see if it was correctly constructed (try the SQL statement from your database shell utility to see if it also gives you an error).
Variable/Function name typos: you should look for consistency of function and/or variable names. For instance, if you have
This will give you a "Divide by zero" error, because you typed $dib instead of $div. Use the search function of your favorite editor to verify that your variable and function names are the same throughout all your script.
Commenting lines to isolate the error: if you are getting errors and cannot find out the reason, you should start commenting lines to isolate the error:
Start commenting the lines that are suspicious. Then, keep commenting until the script does notgive the error. When you reach that point, the last line or lines that you commented may be the source of the error.
Watching a variable's progress: to watch a variable's behavior, you can add lines to print the different values that are assigned to your variables during the execution of your script. For example,
Do not forget to print a reference to know where in the program the variable is getting the printed value, and to add the Mime tag before start outputting to the browser!
Debugging with the Apache file log: finally, you can use the output log of the httpd daemon to know what went wrong. From your Linux console, type:
# cd /var/log/httpd
Apache stores a log of what was wrong when trying to output to the remote browser, and normally the error descriptions are quite informative, so you will not have any problem figuring them out.
These are just a few basic techniques that you can use separately, but you must combine them at your convenience to obtain the best and quickest result.
These are my two cents thoughts about security issues; you should try to have these in mind when building your application:
Back in the seventies, when computer applications were starting to come out, computer programmers began to code in the first languages such as Assembler, COBOL (COmmon Business Oriented Language) and Fortran (FORmula TRANslator). Obviously the computers that ran these programs were old, big, not so powerful machines, and only affordable by big companies such as Bull and IBM. So, they basically used business applications and therefore had to hire teams of programmers in order to maintain and enhance their software. Programmers then had to come up with a collaboration environment so they could understand what they did and standardize the code and procedures in order to optimize the programs and maximize the team efforts.
The computers were not as powerful as today's, memory and storage media were expensive and compilers and interpreters had very limited stack and heap sizes, so programming a complex application efficiently was a hard duty to carry out. Standards were necessary. They learned the hard way, but left us a very good legacy.
Standards will make the application documentation, debugging and enhancing much easier. Also, if you decide to sell it or if it becomes an open source project that will have thousands of programmers involved your use of standards will be essential.
We will go over the basics in standards programming. This is just a summary from my point of view and my experience programming in different platforms and languages. It may differ from other coders' opinions, but I think these are the most important points to have in mind when developing any software application.
System design: as I stated in the first installment, system design is absolutely necessary before you start programming. Whatever design standard you choose, stick to it until the end of the development.
Naming convention: try to come up with a naming convention for programs, libraries, variables, functions, procedures and database elements.
Program structure: structure your program as if it were a cheesecake recipe. Differentiate the different sections of your program (libraries, variables declaration, connection/disconnection to and from database, business logic). The Perl interpreter is flexible and allows you to organize your program the way you want it, but for example COBOL has well defined sections for different tasks. (I can remember some! Identification division : author, program name declaration; File section: file opening; Working-storage section: variables and functions declaration.) You should do the same -perhaps not exactly the same way- with your Perl script. Messy programs are hard to understand, debug and document.
Program comments: you should include two types of documentation in each source script: the header and the detail lines. The header should contain the program name, author, company name, brief description of its functionality, notes, dependencies, and dates for creation and future modifications.
and do not be too extensive either, like:
You are really the one who 'measures' this, but for me a good comment line would be:
Functions and procedures: when you design your application, you will notice that a lot of functions can be resumed and concentrated in one procedure that can be called from different programs. Or, the good programmer will try to abstract as many functions as possible and convert them in one callable with different parameters. This function or callable is basically a function or procedure that will behave based on the parameters that are passed from the program. A function usually accepts parameters and returns values; a procedure accepts parameters but only performs tasks.
What is the advantage of this? First, reusability . For future programs, you will not have to reenter the code -or cut and paste-, you simply call the function or procedure with the correspondent parameters. Second, easier debugging. If you get an error, you just debug the function or procedure, not all the programs that call them, therefore, if you fix it, you will be fixing just once. Third, enhancements . If you want to enhance or modify the behavior of a function or procedure, you just do it once and it will reflect the changes in all the programs that invoke it. Fourth, disk and memory usage. I can keep going but I believe you get the picture...
Libraries: once you have all your functions defined, you will probably store them all in a library to separate them from the main scripts, for easier reading and better deployment. Now, you will also notice that some functions or procedures are applicable only to certain modules. A smart thing to do is to separate or 'categorize' functions and procedures in distinct library files. For example, you could create a library called 'inventory.lib ' containing functions and procedures that are called by all the Inventory module programs.
First, for organization and debugging purposes . Second, to not overload the Perl interpreter (from your script, just declare the libraries that contain the function and procedures that you will use, not more, not less) and improve the application performance.
Some other considerations: whatever you do, do it consistently. If you decide to use the ".pl" extension, do it for all your scripts. If you decide to use long name variables, apply them in all your scripts.
Throughout all these articles I've shown you how to design and implement your web-based application. If you look at it in a generic way, it is really applicable to any other kind of application, and for any kind of operating system and programming language.
It does not matter if your favorite platform is Unix, Linux, Windows, OS/2 or Mac, and it does not matter if you like Perl, C, Java, Visual Basic, or COBOL either. What matters is your passion to develop software that will help you and others to achieve what technology revolution promised twenty years ago: to make our lives easier.
I consider programming as an art. The programmer is an artist who expresses himself through programs that come from his abstraction of a given problem. The good programmer thinks that there will always be a thousand different ways to solve the same problem. "You're not born as a programmer, you make yourself a programmer" they say. This means, skills come with experience. Try to do as many developments as possible, just for fun or for your job; enjoy the challenges, and always think that there is a better way to do it, no matter if you thought about it for months -be a hardcore non-conformist!. Experience will give you expertise, speed and a more exercised brain.
Some problems can be solved with Linux and Perl, some others might be solved with Windows and ASP scripts, or it may be a situation where you have to use the best of both worlds, or look for a different one! Common sense is the programmer's best buddy, and, as my ex-professor of networking used to say, "do not kill an ant with a bazooka, measure your resources" (thanks, Omar!).
I hope you enjoyed this series, and I also hope that it helped you in some way. As always, if you have a question or want to contact me, please feel free to do it by email.
Marcelo Pham is a writer for the Linux.com Develop Section. Marcelo is a systems consultant who was born in Buenos Aires, Argentina, but lives now in sunny Miami, FL.
|Page 1 of 1|