What is a script? A body of Perl code that executes
straight through based on some global data (eg @ARGV),
right?
What is a function? A body of Perl code that executes
straight through, generally based on private data passed
in through @_, right?
While there are some technical differences in how you
write them, there is no real difference in what you can
do with a script and a function. However what you have
written to be called as a function can trivially be
rewritten as a script that just calls that function. The
converse is not true, what is written as a script may take
more work to write as a function.
The upshot of this is that when you want to encapsulate
a bunch of functionality, you are generally better off
thinking about making it a function than making it a
script. And you are better off reaching for functions
than scripts.
If you apply that principle in this case, your problem
resolves itself. Can you write a program that calls two
functions, one to produce the main content and another
to produce the side menu? The answer is that you can. And
if you put the function for the side menu into a module,
you can share that content across many pages very easily.
In fact that is basically how this site works. If you
look at the page, you will see that it is broken up into
various "nodelets". Filling in each nodelet is just a
question of calling a function. And if you register for the
site you will find out that what nodelets you have is
itself configurable - and behind the scenes just represents
a series of choices about which functions to call.
But the principle remains. Whenever possible, encapsulate
functionality in a function, not a script. Do that
consistently and you will find that a lot of technical
problems resolve themselves very directly and naturally,
in fact often so smoothly that you don't even notice that
you might have had a problem if you had done things a
different way. |