Your question seems rather to be "when is a script too minimal?" If the content of the module is sensible, then I have no problem with an entire script looking like:

  use MyModule;
  MyModule->go;
[download]

I see no reason why you'd want to require that a script show some minimum complexity.

The key though is that the module should not just be a dumping ground for the stuff in the script - it should follow the normal principles of module design, so that each method/function should perform a single clearly defined function that is well described by its name, and the collection of methods should be related to each other in a way clearly encapsulated by the module name.

If the module does what it should, and if one of its methods does everything the script wants and needs, then that's an ideal situation.

Hugo

To me that is perfectly fine, there's a lot of software which is a tiny driver program over some library. You probably do want to consider whether you want a single or multiple modules though: separating presentation, application and business logic makes reuse of the components easier.

/J\

I agree with him that a script which has nothing in it but a single call to a module is fine, as is one that just has config info. However, I think your intuition that someting is odd might be coming from another source. You're putting code in the module so it they can be used in more than once. The things that are different from case to case aren't code, however, they are data. Thus the task could also be organized as a single script which selects among configuration as one of its actions. It could take the config data from a hash in the script, a singele config file with sections to choose from, or a set of distinct config files.

In that model, you put the code at the top level of attention, with the config below it. That may be clearer, or it may not, and that's one of the choices you make in deciding what "simple" means in this case and it's context. Putting the config info conceptually below the code is an organization worth considering (and maybe rejecting), but I think that's what's tugging at the intuitions in the back of your head.

By carefully factoring code out of the script into modules, you allow other script and module authors to leverage your code. If you leave everything (or anything) in the script reuse becomes harder, especially if you don't use many subs.

I think of a the ideal script as a mapper between command line arguments and one or more modules (not that I always achieve the ideal).

Phil

As noted, there's nothing wrong with what you've done. Here's a bit more for you to think about.

You've written a class with one constructor and one method. A class has a dual role. First, it must provide everything it needs to provide. That is to say, it must be "complete" and that tends to increase its size. However, a class is also frequently an element of code reuse and then it should be as small as possible. Thus, you have competing pressures on the classes and this can cause difficulties with design.

If you have a small class which does everything you need to do, you really don't have as much worry about that competing pressure and this is a good thing. And if you're really, really crazy, you can read a bit more about the problem and strengths and weaknesses of various solutions to it.

But TIMTOWTDI. Nobody can prevent you from writing a "Hello world" script in the way like this:

#in the file Acme/Helloworld.pm
package Acme::HelloWorld;

use warnings;
use strict;

sub new {my $class = shift; bless {}, $class }
sub helloworld { print "Hello world!\n" }
1;

#in the file helloworld.pl

use Acme::HelloWorld;
my $h = Acme::HelloWorld->new();
$h->helloworld();
[download]

And CGI::Application enforces you to do such things. There is nothing bad in such a way—the worst thing about it is that the executable file does not contain any information about what it really does :)

I don't know your certain case. IMHO if you can do different things (e.g. create different HTML pages for different projects) by modifying only 'config' lines in your script—it's good. Your script is simple enough and your module is complicated enough to fulfil your needs. If you can create only one certain page—there is nothing bad in it, as the page is finally created and from this point of view there is no difference how did you produce it.

Everything should be made as simple as possible, but not one bit simpler.
–Albert Einstein

... and the object would just figure out what mode it was in from the query string and do ... everything. The object will have its own CGI object, its own HTML::Template object and so on.