So, I determined that I would write a book. As I began to think about writing a book, several thoughts dominated. One, the last time that I tried to write a book, it took an ungodly amount of time. Two, there are a large number of other people that are so much more qualified to write this than I - of course none of them have done so, but that's another story. Three, I really want more editorial control over what is said than a real publisher would give me - that is, a publisher that cared much about their reputation. Four, as soon as I got something on paper, either it would have changed, or I would have changed my mind on the subject, and so by the time it was actually printed, I would not want to have my name on it.
So it seemed to make more sense that I put this online, where I would have to solutions to most of the above. The time one is a little sticky, and so this is not likely to actually be finished any time in the next 5 years, but bear with me, and perhaps there will be something here worth reading.
While I could spend a lot of time telling you how this database works, and how Perl can talk to that database, all of that information is freely available on the Internet. I will devote a few appendices to telling you where, but I won’t waste your time and mine in reproducing stuff that you can get for free.
Meanwhile, it would seem that the real value in a tutorial such as this one would be to give you some examples, tips, tricks, and secrets, about effective web database programming, particularly tricks on how to get your work done quickly and painlessly with Perl. As one of my students said of my course, this is not Perl for the student of the theory of programming, but it is Perl for those that need to get their work done.
I have spent the last 2 years writing web database applications in Perl. Most of these were by way of taking paper processes, and putting them online. There are three basic parts of that process. First, you need to understand the paper process, or you have no chance of effectively putting it online. Next, you have to figure out the best way of writing that process into Perl code, for some definition of the word 'best.' Finally, you have to frame the whole application in such a way that people will actually want to use the online version rather than the paper version. If you make it just as complicated, or worse, to use the online version, there is no incentive to change. Or, stated differently, there must be some valid reason for moving it online, otherwise, you should just leave people alone and let them get their job done.
Scripts are tiny bits of code that perform a small number of trivial functions. Often, the term "script" is used to refer to something that controls other programs, such as something that pipes data to sendmail, or launches an application via OLE. A CGI script is most often something that reads in data from a web form, and passes that data on to some other process, such as a database, or sends email, and then returns a "thank you" page to the user.
Applications are things that are of rather larger scope. They have a distinct purpose. They store and retrieve data. They have a lifetime somewhat longer than the typical one or two page views that constitute the life cycle of a form-handler script.
Obviously, this distinction is very subjective and vague.
The first person that wrote and distributed real CGI applications, at least that I was aware of, was Matt Wright. Matt wrote such things as a guestbook program, an online discussion forum, and a graffiti wall. He wrote them a long time ago, and has not seen fit to update them in more than 3 years. That's unfortunate, since I learned much of what I learned in my first days of CGI programming from picking apart Matt's code. Looking at the code now, I see that it has a number of shortcomings, and is not even nearly taking advantage of the strengths of Perl5, or even of Perl4. Matt called them CGI scripts, probably because that was the term that was being used then. But they were applications by all meaningful definitions. A lot of CGI programmers have gotten their start by reading, and trying to fix, Matt's code. Unfortunately, a lot of them stop at that level.
Why do I mention that? Well, because in the book that I was going to write, this chapter was going to be entitled "The Persistence Of Memories." So there.
The reason that data persistence is such an issue in CGI applications is that HTTP is a stateless protocol. Between loading one web page, and loading the one linked from that one, the web server has forgotten everything that it might have known about you, and has to rediscover all those things again. And even those things that it can discover are not very informatiive. Thus, it is up to the application programmer to do all of their own data management, and to find some mechanism for tracking you from one web "hit" to the next one, even if it is just a few seconds later.
I grew up mostly in Kenya, where I had no access to the Internet. When I returned to the US for college, I went to a private college that did not have an Internet connection, but which did have Unix machines. It was there that I learned a whole lot about Unix. And, even though this was in the late 80s and early 90s, I had never seen Windows, and Unix was the first real operating system that I had ever worked with. Lucky me.
When I went to The University of Kentucky in 1992 for grad school, I got hooked on Usenet. I was still using a VT100 hooked into an aging Sequent Symmetry machine in a dark basement somewhere, so had still not really been exposed to much in the way of Wintel machines, although I had played with Win 3.x long enough to know that I did not like it. Of course, my first PC at home came with Win3.11 on it.
One day, I discovered the WWW. I think that this was in early 1993. I had read quite a bit about the WWW, and had tried to get Winsock and Cello to work on my machine at home, without much luck. I was able to use get Lynx working, and that was pretty cool. Then, one day I was over in the Library computer lab, and saw a Mac machine that was running NCSA Mosaic. After using that for about an hour, I was hooked. I got something working at home called "SlipKnot", which was really cool, and the first piece of shareware that I ever actually paid for.
I put up my first web page sortly after that, while a student in the department of Math Sciences at UK. I registered my first domain name in 1995. I have been writing CGI applications since the middle of 1994.
I work at DataBeam, a subsidiary of Lotus, a subsidiary of IBM.
[ TOC ]