The thoughts behind my questions included the following 'Why "our $variable"?' I looked at the 'our' variables. It seemed to me that they should be local to the enclosing module: only the database connect/disconnect subroutine names need be exported. Certainly it seems unwise to write code which exports the database password all over the place. Surely this should not even be hard coded. 'Why "class"?' 'Class' and 'method' are terminology used by OOP. Beginners to Perl will need to learn Perl terminology, and will not find these terms in the index of most extant perl books. Furthermore, how to implement a class in perl needs a tutorial of its own. I note you are equating 'class' with 'package': do you mean by this that a class needs a package of several modules for its implementation? 'Why not CGI.pm?' Beginners will wish to learn to use this module; it is highly thought of. I looked for HTML::Template in Active State, and again in CPAN, with no luck. Incidentally, I noticed that you are making a new database connection each time you call cgi->new. Do you intend this, and if so, why? Regards - Roger - ----- Original Message ----- From: "fliptop" <[EMAIL PROTECTED]> To: "Roger C Haslock" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, June 14, 2001 6:19 PM Subject: Re: beginner's addressbook tutorial - level of presentation > Roger C Haslock wrote: > > > > I find the general level of detail here a bit advanced for a 'beginner'. > > i was wondering whether this would be the case. some readers told me > they thought it wasn't too advanced, but obviously you feel otherwise. > anyone else care to comment on this issue? is the tutorial too advanced > for a cgi beginner? > > > My mind whirls with questions such as > > > > 'Why "our $variable"?' > > an our declaration declars a global variable that will be visible across > its entire lexical scope, even across package boundaries. (shamelessly > plagarized from 'Programming Perl, 3rd Edition', p. 756.) > > all variables in the base class are declared using our so they're > visible to the other packages. > > > 'Why "class"?' > > it's an extension of the 'divide and conquer' technique to coding i > described in step 1. if all your code is crammed into one script, > editing, making changes, finding bugs, etc. can be a nightmare. > spreading the code (and effectively, the tasks) out over several classes > makes it easier and also makes the code reusable. > > > 'Why not CGI.pm?' > > i do use cgi.pm, but only to read in the form parameters. please read > about why i use html::template for more clarification (it's in the > introduction). > > > Can the presentation not be simplified so that we see the solution to the > > primary problem first, and then have the decorations explained afterwards, > > with reasons as to why they are better than the original. > > probably not, since i'm writing all this on the fly. in other words, > had i prepared the entire tutorial in advance, this would be possible. > but since i'm writing and releasing each step one at a time, it's not > exactly feasible. > > > I am acquainted with perl modules and subroutines, and find it confusing > > when a module is mistaken for a class, or a subroutine for a method. I > > accept that one might implement one class, or several classes, within a > > module. > > method - a procedure, function, or subroutine > class = package - a namespace for variables and methods > > keep in mind i'm work on these installments at night after spending 8 > hours programming for my job. ever heard the story about the coffee > shop owner who says at the end of the day, "egad! if i see one more cup > of coffee today....."? ever wonder if male gynocologists have the same > problem? > > anyway, i appreciate your comments and will do what i can to try to > accomodate them. if you have specific questions or problems, don't > hesitate to post to the list. > > >
