package MyAppCommon;
use strict;

sub CommonPageStart {
  ...
}

sub CommonPageEnd {
  ...
}

1;
__END__

# and then, in your scripts
use MyAppCommon;  # use is basically like require... see the docs for 
+details
MyAppCommon::CommonPageStart(...);

# your stuff

MyAppCommon::CommonPageEnd(...);
[download]

As for more direct reasons of why this is better:

• It makes your code more easily maintainable and extensible because your code is organized into packages, and it is namespaced (so you can easily add it to another application without worry of namespace collision, and likewise, other modules can be added to it easily without worry of namespace collision)
• It is more time-efficient. If you "do" a file, it is read off of disk and parsed with each invocation. However, when a file is "use"d or "require"d (same mechanism, mostly) it is only read off of disk and parsed/compiled once. Further references to it are just referring back to the first copy made. In a mod_perl process, for instance, this can lead to enormous speed improvements.
• For much the same reasons, it is more space-efficient. Since the file is only compiled once, the subroutines and data structures and data internal to the perl interpretter (for, say, storing the internal representation of the parsed and compiled code) are only stored once. Again, under mod_perl, this affect can be multiplied even more if your modules are pre-loaded in the parent process (before forking), as each server-process reuses the same copy (more or less) of the compiled code of the modules.
• etc

------------
:Wq
Not an editor command: Wq
[download]

Alright, that sounds good and makes sense. Question though. I'm hosted on a shared hosting.

To make the library, is it just a matter of creating the file with the content you have above, or do I have to do something more specific where I would require higher access to the server (other then FTP)?

If I need access to the server (which I can't get) to create a library like you suggested, would 'require' be a equally decent alternative?

Thx for all the feedback guys! I always learn a ton when I ask for input here. It's greatly appreciated!


Stenyj

No, you don't need to worry about that. Libraries can live anywhere. You just want to add:

use lib qw( /path/to/my/libraries/ );
[download]

At the top of your scripts (or in the initialization file for your web server), to tell perl where to look for libraries. Also, don't let the use scare you. It's built on the same mechanism as require, basically, there's just some more tricks involved. One consequence of those differences, though, is that you have to use module-names (where the path-separator is "::" and the path is relative to the library path(s)) with a use statement, whereas with require, you can use either a module-name or a file-name

The two things that are different between use and require are that

• use happens at BEGIN-time (that is, as the code is being parsed and compiled, rather than later on as the code is being executed). This means, for example, that:

  if (0) {
     use Some::Module;
  }
  [download]

  will still use the module!
• use also automatically calls the import method of whatever module it is loading, and you can specify parameters to that import method after the use statement. (Be careful, though, because since the use is executed earlier than it looks like in the code, passing variables into the import method could cause you hard to understand results... generally just static arguments are passed to the import method this way). For example, look up the page at where I said use lib qw( /path/to/my/libraries/ );, that actually means that lib->import( '/path/to/my/libraries/' ); is getting called (lib being a standard core module for manipulating the directory-path).
This means that use Foo::Bar; is actually equivalent to just:

BEGIN {
   require Foo::Bar;
   Foo::Bar->import();
}
[download]

Of course, if your module doesn't have an import method defined, nothing bad happens, because (since it's a method call, not a function call) it ascends up the class hierarchy to UNIVERSAL::import (...but I'm getting into details, here).

Look at perldoc perlmodlib perldoc perlmod for more info. And good luck!

------------
:Wq
Not an editor command: Wq
[download]

If you are running Perl5, you could do this:

package MyPackage;
use base 'Exporter';
use strict;
use warnings;

our @EXPORT_OK = qw/part1 part3/;

sub part1 { 
    #code for part1
}

sub part3 { 
    #code for part3
}

1;

# then in your script
#!/usr/bin/perl
use MyPackage qw/part1 part3/;
use strict;
use warnings;

part1();
part2();
part3();
exit; 

sub part2 { 
    #code for part2
}
[download]