in reply to form processing problem

Two ways.

The first post shows you the way in which you import a subset of the symbols exported/exportable in CGI package into the current package namespace. Second method, the object-oriented method, in which you work with a reference to an object of CGI 
use strict ;
use warnings ;
use CGI ;
my $query = new CGI ;
my $ime = $query->param('ime'); # will get Janez
my $vzdevek = $query->param('vzdevek'); # will get Yanezh

[download]


Manav

Replies are listed 'Best First'.
Re^2: form processing problem
by merlyn (Sage) on Mar 24, 2005 at 15:59 UTC
    Second method, the object-oriented method, in which you work with a reference to an object of CGI
    And I've never really seen an advantage to that, except to make CGI programming look harder than it needs to look for the beginning programmer.

    Apparently, Lincoln agrees. The latest releases of CGI.pm documentation emphasize the imported version, rather than the object version. Makes the manpage look a whole lot cleaner.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]
      Object oriented approach makes programmers who are conversed with C++ think that they know what's going on... ;)


      Seriously, the given example notwithstanding, I've seen lots of code with 
      use CGI qw/:standard/ ;
print redirect('http://www.nowhere.to.go') ;

      [download]
      I mean, Isnt it useless to clutter up your namespace with imported symbols just to use next-to-nothing from it??


      Manav
[reply]
[d/l]
        Well, in that case, I'd advocate "use CGI 'redirect'", actually.

        But really, at some point, it becomes "the cost of my time to optimize the import or use OO invocations" vs "the cost of 5 hits a minute on a webserver". If the trade is against 50 hits a second, your argument holds water, but at 5 hits a minute (fast even for the majority of operations), who cares? {grin}

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]

      First off, when talking about general advantages of OO vs import-the-world (or import-what-you-need), I'm not sure that we could all agree on a single expert (possibly including Larry). And, even if we could, I'm not sure that Lincoln would necessarily be that expert ;-)

      Secondly, the CGI documentation still states:

      The examples in this document mainly use the object-oriented style.
      It's not entirely clear that Lincoln has a preference.

      Personally, I prefer the OO style to keep things clear in my head where things are coming from. But maybe that's just me. :-)

[reply]
        when talking about general advantages of OO vs import-the-world
        Uh, I wasn't making this a general conversation. I was talking specifically about CGI.pm and the typical use (a singleton object, and with people who probably don't want to grok Perl's OO).

        Please don't light up a different fire. This one fans well enough. {grin}

        Secondly, the CGI documentation still states:
        The examples in this document mainly use the object-oriented style.
        That's a vestigial text. Look at the examples in the rest of the doc. They've been almost entirely converted to import style. This happened quite recently.
        It's not entirely clear that Lincoln has a preference.
        It's very clear to me. I've seen Lincoln talk at conferences. In fact, I even filled in for him once. His slides never use the OO form. That's why I wasn't surprised when he finally changed the manpage.

        -- Randal L. Schwartz, Perl hacker
        Be sure to read my standard disclaimer if this is a reply.

[reply]

In Section Seekers of Perl Wisdom