My original implementation was done early and was somewhat functional, but there were problems with the DBM calls. I had been thinking of redesigning the screens and some of the logic anyway, so to take a break from "perl fighting", came up with a better designed version as the one that I am documenting.
For a long time I was still plagued with DBM problems, even in the second "released" version. I finally realized that in the retrieve module, I was checking if the database existed but using that full name later to open the database. Only the file name, not the period or file extension, should be used in DBM calls.
Once I got the system working, I added a delete capability. Now the user can add, review, or delete records. I could add an update capability, but it would just be a matter of some work and no real new concepts. Now that it finally works, I am reasonably pleased with it!
The user screen that starts the project off simply asks for input and does no error checking. I spent a bit of time researching the text input field, as I have one numeric input (time), but was surprised to find that one can't specify a numeric input field with cgi-bin forms.
The logic of adding records is in dbAddRecord2.pl.cgi and that of retrieving records is in dbRetrieve2.pl.cgi. dbDeleteRecord2.pl.cgi is called from the retrieve routine if a user decides to delete a record. The small utility dbDeleteRecordDoIt2.pl does the actual deletion.
Since DBM databases are single key-value based, I had to
encode all of the values of artist, genre, format, time,
and comments into one value field. At first, I had the
thought to use a string that was very unlikely to be in any
of the text input fields, and encode as follows:
*$[artist]$**$[genre]$* ... *$[comments]$*
However, I found it much easier to parse if I just asked the user not to use the tilde (~) character, and settled on an encoding with tildes between fields as follows:
In any case, this was a simple design choice of using positional parameters.
We adopt a naive model of web users who are all trusted to make database updates. This is possibly plausible on an intranet or inside of some sort of firewall at a small company. In real life, there would need to be authentication so that given userids and passwords could have database access privileges.
A user interface in a real system would allow additional features. Right now, when one views retrieved records, they are not sorted. A real interface would allow sorting by album name, artist, or category -- or perhaps by any field. It would also be expected that one should be able to update existing records.
As with the perl assignment, I found very helpful for the forms design our
forms lesson. Also, I again used
Steven Brenner's library of
Perl Routines to Manipulate CGI input
to parse the input variables. I "met" a perl guru on the net,
Guy Decoux, and he gave me another valuable reference - the perldoc
command for online perl documentation (try "perldoc -f
Return to home page
Execute the code
Background courtesy of
Moyra's Web Jewels