in reply to Mid-row colspans with CGI.pm

I hate $q->... when using CGI.pm, so I'd write that whole thing as: 
use CGI::Pretty qw(:standard);
print table({border=>1, cellspacing=>2, cellpadding=>2},
  Tr({align=>'left', valign=>'center'}, [
    td([qw(one 1 I)]),
    td([qw(one 1 I)]),
    td('two').td({colspan=>2}, 2),
    td({colspan=>2}, 'three').td('III'),
    td({colspan=>3}, 'four'),
]));

[download]
Just remember... if you don't have more than one element, don't use an arrayref below a shortcut. It merely gets confusing. {grin}

And don't colspan for more columns than you have...

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
RE: (2) Mid-row colspans with CGI.pm ($q-)
by ybiC (Prior) on Oct 03, 2000 at 16:48 UTC
    In the reletively short time I've been using CGI.pm, I've done it sans $q->, like merlyn shows above.   Are there situations with CGI.pm where the extra typing of $q-> provides any benefit or advantage?
        cheers,
        ybiC
[reply]

      If you use other modules along with CGI.pm and any of those other modules export a function whose name is the same as an HTML tag name, then you'll have to have either CGI.pm or that other module not export that particular function. The object notation allows CGI.pm to not export tons of symbols while providing you an easy way to get to all of the CGI routines.

      You could probably also use CGI::td() to similar effect, though that may raise issues of which sub-module each routine comes from -- since I haven't see this documented I wouldn't consider it supported and so wouldn't recommend it. I just mention this because it is the other standard way to avoid collisions in your global namespace.

      Usually object notation is a good thing for Perl modules because it allows you to not pollute your global name space with lots of imported functions that may clash as you use more modules. It is also good because it usually gets the module author to allow multiple simultaneous uses of that module with different configurations.

      I find it hard to image a case where one script would need more than one CGI object. So it is just a matter of trade-off of not having to type $q-> vs. not having your global namespace "polluted" with tons of short names.

              - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]
      I like the $q->x() OO style syntax :-), looks nicer, and I dont use the $q->hr, $q->table HTML tags.
      Thats the reason I use CGI that way, on systems (Intranet, low volume) where you can ignore performance to a point.

[reply]
      Lincoln Stein himself uses the functional interface in all his training examples. I can see three times to use the object interface (mind you I just woke up five minutes ago {grin}):
      • When I'm unsure if saying use CGI qw(:standard) will collide with existing subroutines, such as grafting a CGI front onto some previous command-line program
      • In a mod_perl environment, to keep from creating 240 stabs (as we discussed earlier in a thread about CGI.pm's performance) in each Apache::Registry-managed handler
      • When I want to have more than one CGI object in a single program (to save and restore parameters to persistant storage, for example)
      Other than that, use the functional form! Much less typing.

      -- Randal L. Schwartz, Perl hacker

[reply]

In Section Seekers of Perl Wisdom