greetings brothers and sisters,

upon my path I have largely been using Perl for CGI work. This is not uncommon, and I learned long ago that CGI.pm is your best friend. There has always been something that has troubled me, though, and it recently came to light again when reading up on CGI::Application.

For me, these modules try to do too much.

Let me explain my blasphemy against CGI.pm before I'm branded a heretic. And I'll note that I do still use it, even if I'm a bit unhappy with it. For me, I am quite enamored with CGI.pm's ability to parse out all the input my script could ever want. But I have absolutely no use for it's HTML generation facilities.

I imagine it was around long before the tools I use now, but I much prefer using a templating system (namely Template Toolkit) for my document generation. How I've longed to cleave CGI.pm in two, leaving by the wayside the html generation and holding onto it's wonderful parsing abilities.

The problem also arose when I learned that CGI::Application is tied internally to HTML::Template. A worthy module to be sure, I have already mentioned that I prefer the Template Toolkit, as my applications output more than just web pages.

While it is possible to override this relationship I am wondering:

  1. what unused overhead I'm stuck with by discarding this feature in preference of something extra i must implement, and
  2. why CGI::Application chose to get in bed with one of a myriad of templating modules, when some of the very first words in the documentation state that it is intended to avoid binding a developer to any particular tools.

I think i personally would have been happiest if CGI::Application hadn't strayed from the goals of being a solid application framework module.

My questions to the perlmonks community is what do you consider when defining the scope/granularity of your own modules? What does the perl community at large have to say about such things? Have any of you had similar experiences with popular modules that for you seemed a bit bloated in the light of your own projects?

Replies are listed 'Best First'.
Re: Modules that do Less
by davorg (Chancellor) on Jun 12, 2001 at 12:13 UTC

    This is a common criticism of CGI.pm, but it's one that's totally unfair. CGI.pm makes it very simple to load just the bits of it that you need. There are a large number of export tag sets defined, it's just a case of choosing the one(s) that you need.

    Like you, I find myself using the Template Toolkit for many of my CGI scripts and only use CGI.pm for the actual CGI protocol. I therefore find most of my CGI scripts starting out something like this:

    use CGI qw(param header);
use Template;

    [download]

    As an aside, Lincoln Stein has been promising to split CGI.pm into separate modules for some time, but I'm not sure how far he's got with the project.

    --
    <http://www.dave.org.uk>

    Perl Training in the UK <http://www.iterative-software.com>

[reply]
[d/l]

      A very good point, and perhaps this speaks to an area of weakness in my Perl knowledge. Extrapolating to a more general scenario:

      There's a module that I'd like to use. It does everything under the sun for a particular area of expertise. I want to use three of its functions, and export only those. Do I or do I not get a penalty in terms of memory/compile speed for having to load the rest of the module into memory at compile time? Even if only those three functions are imported into my name space?

[reply]

        If the module uses AutoLoading or SelfLoading or something similar, than the cost is nearly zero. If the module doesn't, then you might want to patch it so that it does and submit the patch to the author. Large modules should do this for the reasons you give.

                - tye (but my friends call me "Tye")
[reply]
Re: Modules that do Less
by stephen (Priest) on Jun 12, 2001 at 18:46 UTC

    I do agree that modules sometimes grow larger than is healthy for them. There's always the temptation to add that one additional feature-- it'd be cool, and wouldn't hurt anything, one thinks to oneself. Following this path, one can end up with a module so bloated it's difficult to understand. A module should do one thing and do it well.

    Even so, I think that CGI doesn't fall into that category. Even if it has some features that you don't use, these functions aren't hurting you because until you use them they're not even compiled. From Lincoln Stein's web site:

    Ordinarily CGI.pm autoloads most of its functions on an as-needed basis. This speeds up the loading time by deferring the compilation phase.

    In other words, there's rarely any reason to worry about loading CGI.pm. It loads in only the parts that you use.

    stephen

[reply]
      Having not read the code for CGI.pm, I'm wondering how this is done. Is this a Perl feature or do you have to do a huge amount of contortions to get this to happen?
[reply]
        A bit of both. CGI goes through huge contortions to do its version of autoloading, because Lincoln Stein is a very clever man who wanted to do things his way. However, using the SelfLoader is pretty simple; you put your functions after a '__DATA__' token and say 'use SelfLoader' at the top. The AutoLoader module is a bit more complicated, but can offer better results.

        stephen

[reply]
      Thanks, I hadn't visited his web site. This was exactly what I was wondering.
[reply]
Re: Modules that do Less
by markjugg (Curate) on Jul 18, 2001 at 08:30 UTC
    Regarding CGI::Appplication and HTML::Template, in a recent version of the module, the code was updated to "require" HTML::Template when you called load_tmpl() rather than "use" it all the time. That function is just a convenience hook-- You can use any other templating system with CGI::App without fear of penalty. Personally I prefer HTML::Template. :)

    -mark

[reply]
      Hehe, I know about the update. I was the one who proposed it and presented Jesse with the patch :)
[reply]
        I suppose I would have noticed if I knew AidanLee == Stephen Howard. Now we know. :)

        -mark

[reply]

Back to Meditations