FW: [Tallahassee-pm] Questions and such

[Tillman, James]

And again I forget to copy the list!  Tsk, tsk, tsk.

jpt

> -----Original Message-----
> From: Tillman, James 
> Sent: Tuesday, July 01, 2003 10:53 AM
> To: 'Rebekah Landbeck'
> Subject: RE: [Tallahassee-pm] Questions and such
> 
> 
> > Whoever wrote this app wrote each CGI script as if it were 
> > the only one in the whole thing.  Code is duplicated all over 
> > the place, particularly database connection stuff.  I need to 
> > consolidate all the database code into a package because the 
> > connection info varies.  
> 
> I would consider this a good approach to take.
>  
> > Questions concerning Exporter:
> > 
> > 1)  Is using Exporter necessary/the best way to include a 
> > seperate package file?
> 
> Exporter is only necessary if you plan to export stuff into 
> the use'ing module's namespace.  Essentially, what happens 
> when you "export" is that the variables and functions you 
> export appear as if they were declared in the "use'ing 
> module," instead of the module that "got used".  This can 
> cause confusion if you export stuff that the use'ing module 
> doesn't expect, and you might even clobber their own 
> variables or methods if theirs have the same name.
> 
> So exporting should be used with care, and very rarely, in my 
> opinion.  Others may differ with me on this.  Use of Exporter 
> is, therefore, optional, and can be safely left out of your 
> package altogether.
>  
> > 2)  The PHP include() reads the file into the current one as 
> > if the code were written in the current file.  I haven't come 
> > across anything that I can recall in PHP regarding 
> > namespaces, but I have an ok grasp of the concept.  I think.  
> > The Exporter doc says "use ModuleName; This imports all the 
> > symbols from ModuleName's @EXPORT into the namespace of the 
> > use statement." Does that essentially mean the same thing?
> 
> PHP only recently began supporting namespaces, and almost no 
> existing common code uses it that I'm aware of. (Correct me 
> if I'm wrong, guys).  What the Exporter docs are saying is 
> that if a variable name or function name is included in the 
> @EXPORT array, it will be added to the use'ing module's namespace.
>  
> > 3)  I read that exporting method names isn't good.  Is that 
> > why you would use Modulename();, importing no symbols?
> 
> Yes.  People sometimes use the () to prevent imports from 
> happening.  The clobbering/confusion effect can be prevented 
> using that syntax.
>  
> > 4)  It seems that 'symbols' refers to references to variable 
> > names or to sub names.  Is that right?
> 
> Yes.  As I said before, you can sometimes get a little 
> overdose on computer science terminology from the Perl docs.
>  
> The way I've handled the db connection issue in the past has 
> varied, but the cleanest I've found is to create a 
> non-object-oriented Perl module (the easiest to create) like this:
> 
> package DB;
> 
> use strict;
> use vars qw/$db/;  # This allows us to create a package level 
> variable in spite of
>                    # the "use strict" directive.  Otherwise, 
> we'd have to use 
>                    #  "my $db" and my'ed variables aren't 
> available outside the 
>                    # current package (namespace) at all.
> 
> $db = {
> 	username => 'myUser',
> 	password => 'myPassword',
> 	connect_string => 'dbi:ODBC:DSNName',  #or whatever 
> connection string is right for you
> };
> 
> 1; # This is required to avoid problems with modules.  The 
> docs on create modules mention why.
> 
> # Then in your CGI script you could do this:
> 
> use DB;
> my $db = $DB::db; #Creates a variable in the current package 
> that points to the variable in 
>                   # in the DB module.  Better than importing!
> 
> # Then you can get the variables out using this syntax:
> 
> print "My conect_string is: " . $db->{connect_string} . "\n";
> 
> # Of course it would be better to add a get_connection() 
> function to your DB package, which 
> # would return a fully connected DBI connection:
> use DBI;
> sub get_connection {
> 	my $dbh = DBI->connect($db->{connect_string}, 
> $db->{username}, $db->{password});
> 	return $dbh;
> }
> 
> # And then you could just do this in your CGI script:
> 
> my $dbh = DB::get_connection();
> -------------------
> 
> I hope this helps a little.  Let me know if I've just muddied 
> the waters.
> 
> jpt
>