Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

CGI.pm vs. CGI modules

by rruiz (Monk)
on Oct 17, 2002 at 05:20 UTC ( #205933=perlquestion: print w/ replies, xml ) Need Help??
rruiz has asked for the wisdom of the Perl Monks concerning the following question:

Hello there, God bless you.

I am sorry if this has been asked many times before, but the most recent reference I could find in this site is the node Has there been a new CGI..., which is dated Feb, 21 2001. Althrought, it is not the closets related to what I am talking about here, it is close enought (I think... mmm...)

What I want to know/ask is: What is the best way to go about CGI programming: using CGI.pm or the CGI modules to program a CGI's in Perl? What do you think is going to last the most?

Before researching into this matter, I thought that CGI modules was faster than CGI.pm programming (CGI:Base and related vs CGI), but reading the documentation on CGI::Form, it says it is slower to boot than CGI.pm related stuff because of the flexibility innherent to it.

So, the question is: Should I stay with CGI.pm or should I go for CGI::Base and related modules?

I have seen that almost everyone here is using CGI.pm, but reading the documentation for CGI::Base and related modules, I can read that using CGI::Base + HTML.pm + URI::Escape.pm is equivalent to using CGI.pm. And taken into account that, as far as I can tell, it is best for a piece of software to do the least amount of work, and cooperate with other pieces of software to do the work... I want to know/ask here: What do you think is the best way to do CGI development in Perl: Using the CGI.pm module or using the CGI::Base (and HTML, and HTTP and URI, and etc.) related modules?

As far as I can see, there have been quite a few questions about separating HTML generation from CGI processing lately, that's why I think this is a good question to ask for.

Hope this make some sense to you and you can help me decide what is the best way to go about developing CGI's in Perl. Thanks in advance for the thoughts you can bring into this matter for me.

Roberto Ruiz.

ps. Sorry for my English if it is not good enought. :)

Comment on CGI.pm vs. CGI modules
Re: CGI.pm vs. CGI modules
by Aragorn (Curate) on Oct 17, 2002 at 07:04 UTC
    CGI.pm is included with the Perl core distribution, so you can reasonably expect your code to run pretty much anywhere (barring other non-portable things of course). This may or may not be an advantage for you.

    I agree with you that clear separation of functionality is a good thing, and that CGI.pm tries to do everything. Even the author of CGI.pm admits that it should be discarded in favour of better-designed modules.

    As with anything, I think it depends on what you want to do. I'm only familiar with CGI.pm, and know nothing (yet :-) about the other CGI modules you mention. If the separate modules (CGI::Base, etc.) have the functionality you need, I'd say go for it, and don't use CGI.pm.

    --
    All that is gold does not glitter...

Re: CGI.pm vs. CGI modules
by jarich (Curate) on Oct 17, 2002 at 07:40 UTC
    For what it's worth I recommend CGI::Simple (code here) and HTML::Template. If you need to generate html code specifically then there are a bunch of CGI modules that'll help you create and fill in forms etc. The right one depends on what you're doing.

    I'm not sure what this HTML.pm that you speak of is, but I'm sure it'd be useful too.

    CGI::Simple.pm is a reworked version of CGI.pm which is clean, strict compliant and fast to load. It doesn't do all the CGI.pm does, as far as I know, as the HTML generation subroutines were left by the wayside (probably not a bad thing since you want to be using templates anyway).

    I suspect that you'll find that "the best way" to go about CGI programming is to use the modules that do as much of the work for you as possible. We don't jump up and down on people here just because they didn't use CGI.pm, we jump up and down on them because they attempted (and failed) to write their own version of stuff that CGI.pm happens to do well. So long as you use a module that does what you need it to and is tested (and is hopefully above version 1.0) you're doing the right thing.

    Hope it helps.

    jarich

Re: CGI.pm vs. CGI modules
by mshiltonj (Sexton) on Oct 17, 2002 at 10:41 UTC
    I suggest checking out CGI::Application. It makes creating a complex cgi app a lot easier, and has hooks into HTML::Template. The more I use it, the more awkward it seems when I'm not using it.

      Yes, the moment I read about CGI::Application on the post My experiences using CGI::Aplication... by scazat, I realized it was a great module. Unfortunately, my host provider does not have it installed, I will be looking into the posibilities for them to install both modules, but mean while I need to analyse the best path to make my CGI's using the modules they have already installed.

      Also a big thank you very much for you and for everybody else for your comments in this node. ;)

        Note that if you can upload scripts, you can also install modules, pure-Perl ones at least. Just fetch the tarball, install it locally to some subdirectory, upload that to your host, and use lib in the script to point at the path they can be found at before you use the modules in question.

        Makeshifts last the longest.

Re: CGI.pm vs. CGI modules
by perrin (Chancellor) on Oct 17, 2002 at 15:24 UTC
    I asked about this here.

    CGI::Simple offers an API that matches CGI.pm but is faster and uses less memory. CGI_Lite is faster still, but doesn't have the same API so you would have to modify code to use it. The main reasons for sticking with CGI.pm are that it's in the standard Perl distribution and it is well-maintained so you can count on problems with it being fixed pretty quickly.

TIMTOWTDY
by kha0z (Scribe) on Oct 18, 2002 at 07:11 UTC
    This is a fair question. The answer does present itself easily. As the other posts have indicated, each module offeres clear advantages and disadvantages over the others. In reality, I think that this question is better answered by taking a step back and looking at the problem that you are trying to solve.

    In most cases, CGI.pm and all the other modules offer many APIs to allow faster development of CGI applications. The difference that needs to be initially noted, is a clear definition of the problem. What is this CGI application going in accomplish? What type of traffic will this CGI application be taking? Are you limited by the hardware resources to accomplish this task? What is the most efficient way to solve the problem?

    As always, there is more than one way to do it.

    If you are going to be developing an application that has a specific task and is expected to take lots of requests and requires maximum optimization, then you really need to research the modules that you need to avoid loading unnecessary code. This will allow the Perl interpreter to process your script faster and return the response to the web server in less time. For this senario, I would suggest to refrain from using any modules that do more than you need. In other words, scrap CGI.pm and load the specific modules to the tast your script is going to do.

    If performance is not the concern but portability and scalability. I would then recomment to load the larger more featured modules to allow for easier development and try to choose modules that are supported across mutliple platforms. In this case, CGI.pm would be better suited to your needs.

    I hope this helps.

    Good Hunting,
    kha0z

      You are absolutly right, thank you very much for your insights, they are terrific (like in very good).

      I should learn to code first and then try to optimize/use the best thing there is to use... As you point out, it is a must to think more into the problem at hand, as it results that the script I am going to program will not be used heavily and there is not much point to optimize it at this time.

      Best regards
      rruiz

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://205933]
Approved by schumi
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (8)
As of 2014-10-22 12:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (117 votes), past polls