Home Tutorial Mods Configurator Bookstore Links Email JPDeni

Up to this point, you have been able to pretty much "cut and paste" code from the tutorial or enter a number or two. In order to have a very nicely functioning database, you don't need to go any further. But if you would like to make some modifications or have your database look a little differently, you'll need to do some more work.

I think the best things to do now is tell you a little bit about Perl, the language that DBMan is written in. If you understand some simple concepts, it will be much easier to explain how to make changes to the database. This is not a complete description of the Perl language, though. These are just some of the concepts that will help you directly with DBMan. If you would like more information on Perl, take a look at the resources in the Bookstore.

After reading everything I wrote here, I realize that there's a lot to absorb. Don't worry if you can't remember everything. This is just an introduction to concepts so you will understand the next steps. It will be worth your while to read this page.

The cardinal rule

One very basic thing that you need to keep in mind is that

every Perl command must end in a semi-colon => ; <=

(Do you get the impression that this is important? Good. It is.) If you get a "500 Error" when you run your script, the first thing to look for is a missing semi-colon at the end of some line. This is also one reason that I suggest very strongly that you only make a few changes at a time. It makes it much easier to find errors.

Comment lines

Alex Krohn is an excellent programmer and he does what excellent programmers do. He makes comments in his code to explain what the code does. I need to take lessons from Alex, because I forget to make comments most of the time.

In Perl, a comment line starts with a #. Any line that begins with a # will be ignored by Perl when the script is run. It is also possible to add a comment to the end of a line, after the semi-colon (remember the semi-colon?). There are a lot of those in the DBMan scripts, too.

It wouldn't be a bad idea for you to make some notes to yourself within the script as you work. Just be sure to add a # before you're comment and you'll be all set. Also, it would be a very good idea for you to read the comment lines within the scripts, especially in the parts you're working on. There is excellent information there.

Quotation Marks

When we read a book, we know where a quotation begins and ends by using quotation marks -- " ... " Perl uses these too, for much the same reason. You will usually see quotation marks associated with a print statement in DBMan. Everything that goes on the html pages which DBMan creates must be printed to the page. The quotation marks tell the script which characters you want to print.

However, there is a little more to quotation marks in Perl that just sticking a " at each end of what you want printed.

There are a number of different types of quotation marks in Perl, each having its own use.

You may have noticed in the default.cfg file there were some places which used single quotes -- '...' If you use single quotes, Perl will print exactly what is between the quotes. It won't try to substitute a variable value or do any computation. What you see is what you get. These can be very useful at times. You do have to remember, though, that you cannot use an apostrophe within single quotes, since it's the same character. For example, if I used 'JPDeni's DBMan-ual', Perl would only recognize that JPDeni was within quotes.

The second type of quotation mark you will see is the double quote -- "..." If you use double quotes, you can use apostrophes and Perl will also substitute a value for any variables it finds within the quotes. For example, if had defined a variable -- $name = 'Fred'; -- I could use it like this:

print "My name is $name";

and the result would be

My name is Fred.

Since most of what we're going to be doing in DBMan is printing out the values of variables, the double quotes are extremely handy.

However (you knew that was coming, didn't you?), double quotes have their drawbacks, too, especially when you're dealing with html pages. There are a number of times, such as entering the URL for a website, when you need to print out double quotes.

All is not lost. You have two options. I'll talk about the one I like best -- and you will see most in the scripts -- first.

Instead of quotes you can use a structure like qq|...| If I used this structure in my example above, I would get the same results:

print qq|My name is $name.|;

the result would be

My name is Fred.

The advantage is that I can also use quotation marks within my statement:

print qq|They call me "$name."|;

the result would be

The call me "Fred."

You can use characters other than the | with the qq. In fact you can use any character you want except a letter, a number or a space. (There are a couple of other characters you can't use too, but I can guaranteee you wouldn't think of them.) The choice of the character is pretty much up to you, except that the character cannot appear within your string. (For purists who know the exception to this rule, I'll get to it in a bit.) Since the | character isn't used very much, I would suggest you use it.

Now to the exception. If you need to use your quote character within your quoted text, you can escape the character by placing a \ in front of it. So I could use

print "They call me \"$name.\"";

and I would still get

They call me "Fred."

This is that other option I mentioned above. I think it's confusing, though.

In general, you can be pretty safe if you use print qq|...| for your print statements.

Whichever kind of quotation marks you use, don't forget to close them off. This is another very common error and your script will not run if you are missing even one quotation mark.

Brackets, Braces and Parentheses

One of the things I have the most problem with is using the correct form of punctuation. Sometimes it's just that I forget which one I'm using. Another problem is that often they look the same, depending on what kind of font you're using.

These are brackets -- [   ]

These are braces (sometimes called "curly braces") -- {  }

These are parentheses (but you already knew that, didn't you?) -- (  )

Subroutines

DBMan has subroutines all over the place. Almost all of the html.pl, auth.pl and db.cgi scripts are subroutines. I'm not going to go into a whole lot of detail about them, because you probably won't be writing your own subroutines for quite a while. (If you could write your own subroutines, you wouldn't need this tutorial!)

If you open up the html.pl file -- the file we're going to be working with for quite a while -- you will see that it starts with a section of comment lines and then some scalar variables are defined. What follows next is a subroutine -- sub html_record_form. You should notice a couple of things about the subroutine that all of them have in common. It starts with the word sub which is then followed by the name of the subroutine. The last thing on the line is a {, a "left" curly brace. If you look further down on the script, you'll see that, just before the next subroutine starts, there is a }, a "right" curly brace.

When a subroutine is used, the syntax is &subroutine_name;. Sometimes values are passed to the subroutine -- &subroutine_name($value);

if ... elsif ... else

The last thing I want to talk about here are "if" statements. You might have occasion to use them, especially if you want to have fields that only certain people can see. I'll go into more detail when we get to them, but for now I just want to show you the format of the statements.

     if (condition) {
       action;
     }
     elsif (another condition) {
       another action;
     }
     else {
       still another action;
     }

By the way, elsif is not a typo. That's how it's supposed to be spelled.

You can have an "if" statement without an "elsif" or an "else," but you can't have an "elsif" or an "else" without an "if."

I find it easier to see what I'm doing if I indent the lines like I have above. As with subroutines, each curly brace has to have a match and it's easier to see whether they match if the lines are indented.

I think that's enough for now. Go take a break and let some of this fester in your brain before you go on.