Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Re: Replacement for CGI.pm

Reply
Thread Tools

Re: Replacement for CGI.pm

 
 
Marius Gavrilescu
Guest
Posts: n/a
 
      10-22-2013
Bernie Cosell <(E-Mail Removed)> writes:

> CGI.pm is very old and I gather that its use is deprecated. Is there a
> better/newer package for handling the CGI interface between Perl and the
> web server? We use it both ways: to parse the incoming variables [and
> cookies] and to generate the outgoing HTML. Our needs are pretty simple:
> just those two functions. It seems to work, and we really haven't had any
> trouble, but see more and more reports that one should *never* use
> CGI.pm... And so : if not, what to use instead? THANKS!!
>
> /Bernie\


If what you have works and you don't intend to change it, then there is
no reason to replace CGI.pm with something else.

Otherwise, CGI.pm is still good for parsing incoming variables. However,
you should use a template system for generating HTML. I personally use
HTML::Template::Compiled, but Template::Toolkit seems to be the most
used/best one.
--
Marius Gavrilescu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBCgAGBQJSZobUAAoJEMoENb5ewbNitggP/iGxRz1mIsfwSRNcLgJaxIk1
8cLGxLXbofUtH0/d6nsH3/pylZcoGmOPbaUERzF3MqOT6FaOWVq5G7fheFaLQmvG
S2WgJ9R5Gl98sdWcuS9cI1521R+1N075u+ZfMHK69W3y3QDDDr UG31uRDOBLGxj3
lFC2cW54BF/EKSK23Bha5BFI8P07/5Z5DYzuRj2LzHe3f8Dcvn7HtPYvSgJE5c26
C38oP66mQQVNtkEWwBbAUoWXTQiHQ0pQA+VmOVOu74X1KO3So7 PHodu0zn5ZX8D5
gh6USsaIpRGiYyqcNQUhuS33h0Pdnid1dGtxiip+EjWe/WW3OB/+EQwrsjZnvMXS
n1Ji2shwIrumlDyadeToq7ewwDMQmgZ3nKlWIcbJr1jmY+5JTf 8EDEiv1tGCx81P
PlrP+CwQ+O0myrNCGrQXsXZNMa3KcRORUO6gNOeY66tVX8+mnU 8jJbhZPTEpgfoA
ur5TyJjWUaP9K2YzkiAu6IBQqHFCsPp9JsecM89Yjxji6zsOxl 87wyaOf1YhcJTu
67TCtD//jk7PZDKgK37/kMrcufHF2e30CdrJLGgsXyC48brkHYKJ3rkXlWPXP4c9
wAKNiRoM7QHLmq1jQMcAt+S4aax339dMElZVHhJTO9QnKSbuFx 0c6lnJyr50hoEL
6fBnKYWbOJnX5Ri3Muz9
=liwd
-----END PGP SIGNATURE-----
 
Reply With Quote
 
 
 
 
Joachim Pense
Guest
Posts: n/a
 
      10-22-2013
Am 22.10.2013 16:08, schrieb Marius Gavrilescu:
>
> Otherwise, CGI.pm is still good for parsing incoming variables. However,
> you should use a template system for generating HTML. I personally use
> HTML::Template::Compiled, but Template::Toolkit seems to be the most
> used/best one.
>


I feel that writing HTML using CGI.pm with its factoring possibilities
is far more elegant than using templates; I use it even for static web
pages. The goal is never use any of < and > when writing HTML.

Joachim
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      10-22-2013
Joachim Pense <(E-Mail Removed)> writes:
> Am 22.10.2013 16:08, schrieb Marius Gavrilescu:
>>
>> Otherwise, CGI.pm is still good for parsing incoming variables. However,
>> you should use a template system for generating HTML. I personally use
>> HTML::Template::Compiled, but Template::Toolkit seems to be the most
>> used/best one.
>>

>
> I feel that writing HTML using CGI.pm with its factoring possibilities
> is far more elegant than using templates; I use it even for static web
> pages. The goal is never use any of < and > when writing HTML.


I'd like to second that, at least to a degree: Especially when building
user interfaces, the abstraction, conditional execution and repetition
facilities of a 'real' programming language enable working with form
elements at a much higher level than HTML or 'some templating languages
based on html'[*] usually do. Eg, this is a (partial) real-world example
of code creating a form:

sub form()
{
return ($cgi->start_form(-action => 'vmecs-create.cgi'),

$cgi->table(7, #{ border => 1 },
$cgi->t_r(menu('company')),

$cgi->empty_line(),

two_params(['name', 20, MAX_DNS_LABEL],
['dns_domain', 40, MAX_DNS_NAME]),

$cgi->empty_line(),

two_params(['ipv4_addr', MAX_DOTTED_QUAD],
['netmask', MAX_DOTTED_QUAD]),
$cgi->flush_right(3,
param('gate', MAX_DOTTED_QUAD)),

$cgi->empty_line(),

two_params(['pool_net', MAX_DOTTED_QUAD],
['pool_mask', MAX_DOTTED_QUAD]),
$cgi->flush_right(3,
param('pool_size', MAX_U32)),

[...]
[*] The only template-system I'm somewhat familiar with is JSF/
RichFaces.
 
Reply With Quote
 
John Bokma
Guest
Posts: n/a
 
      10-22-2013
Rainer Weikusat <(E-Mail Removed)> writes:

> I'd like to second that, at least to a degree: Especially when building
> user interfaces, the abstraction, conditional execution and repetition
> facilities of a 'real' programming language enable working with form
> elements at a much higher level than HTML or 'some templating languages
> based on html'[*] usually do. Eg, this is a (partial) real-world example
> of code creating a form:
>
> sub form()
> {
> return ($cgi->start_form(-action => 'vmecs-create.cgi'),
>
> $cgi->table(7, #{ border => 1 },
> $cgi->t_r(menu('company')),
>
> $cgi->empty_line(),
>
> two_params(['name', 20, MAX_DNS_LABEL],
> ['dns_domain', 40, MAX_DNS_NAME]),


With TT you can make a macro to do this. That's what I've been doing the
past years; I have several macros that make building forms very easy,

Conditional execution and repetition are all easy to do with
Template::Toolkit.


--
John Bokma j3b

Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-ex...for-books.html
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      10-23-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Joachim Pense <(E-Mail Removed)> writes:
>> >
>> > I feel that writing HTML using CGI.pm with its factoring possibilities
>> > is far more elegant than using templates; I use it even for static web
>> > pages. The goal is never use any of < and > when writing HTML.

>>
>> I'd like to second that, at least to a degree: Especially when building
>> user interfaces, the abstraction, conditional execution and repetition
>> facilities of a 'real' programming language enable working with form
>> elements at a much higher level than HTML or 'some templating languages
>> based on html'[*] usually do.

>
> TT2 allows all those things, with the advantage of not being Turing-
> complete. This may seem like a disadvantage, but it actually makes your
> code much cleaner if you keep the business logic out of the templates
> and allow them to concentrate on presentation.


It actually makes my code much cleaner when I can use a more powerful
programming language to build domain-specific abstractions for output
generation instead of being restricted to the 'generic, interpolated tag
soup' model, IOW, HTML-generation is a complex task in its own right and
using some kind of 'Logo for HTML-Editor-Jet-Pilots' instead just
restricts the options available to me for doing that. There's an "It
could be done, hence, it will be done" assumption in your statement
which is really a non-sequitur: Options don't chose themselves (I'm also
firmly convinced that the idea to stop people from making bad choices by
preventing them from making any choices is very misguided: If someone
thinks $opinion is really the Right Thing To Do[tm], the sensible
approach is to try to educate others to help them see the error in their
ways, not to force them to pay as little lip service to the superior
approach as they're capable of getting away with grudgingly).

There was no general 'program logic' not related to output generation in
the code snipped I posted. The code which is supposed to process the
inputs gathered from the form in order to effect something is
different but since the whole is just 723 lines of text, splitting the
logically separate parts into different files didn't seem necessary to
me.

> In the MVC model templates are the View, meaning they should be
> presenting data- and object structures built by the Model and the
> Controller.


'The Model and the Controller' sounds very much like 'The Beauty and the
Beast' (or maybe 'the young, female intern and the hideous accountant'
:->) to me ...
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      10-24-2013
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> >
>> > TT2 allows all those things, with the advantage of not being Turing-
>> > complete. This may seem like a disadvantage, but it actually makes your
>> > code much cleaner if you keep the business logic out of the templates
>> > and allow them to concentrate on presentation.

>>
>> It actually makes my code much cleaner when I can use a more powerful
>> programming language to build domain-specific abstractions for output
>> generation instead of being restricted to the 'generic, interpolated tag
>> soup' model, IOW, HTML-generation is a complex task in its own right

>
> I have to disagree there. It really isn't that complicated to generate
> the HTML once you've got as far as a data structure suitable for
> display,


I wrote 'complex' and not 'complicated' and did so for a reason: That
would mean a broadly-defined 'general task' (ie "generate the HTML")
which is really composed of a set of similar-but-different subtasks
which can further be divided into sub-subtasks and so on, with a
sufficient amount of repetition at each level that 'abstraction' is both
possible and sensible and a sufficient amount of variance that "copy and
paste" ....

> and the sort of abstraction which is helpful is better provided
> by a slightly-souped-up macro language than by a full programming
> language.


.... or programmed "copy and paste" aka macro expansion (using some toy
language) are not really sufficient to solve to problem in a technically
sensible and reasonably easy-to-use way. I don't know of you ever came
across that,

http://thewml.org

qbut that's something I used to use in the past for 'more complicated
stuff' and I have - at one point or another, often within a single
project - actually made use of most features provided by it, and the
ability to 'write a program to write programs' wasn't the least used one
--- the WML macro processor seems more powerful to me than the 'TT' one
(based on looking at the documentation) and I have encountered
situations where it wasn't powerful enough. Also, textual substitution
is a PITA compared to real subroutines once things get 'interesting',
ie, at higher nesting levels.

[Random corollary: It is said that the purpose of Perl would be to make
the simple things easy and the complicated ones possible. Expanding on
that, the purpose of a 'web framework' would be to make the simple
things complicated and relegate the complicated ones to the realm of
fable.]

[...]

>> and using some kind of 'Logo for HTML-Editor-Jet-Pilots' instead just
>> restricts the options available to me for doing that. There's an "It
>> could be done, hence, it will be done" assumption in your statement
>> which is really a non-sequitur: Options don't chose themselves (I'm also
>> firmly convinced that the idea to stop people from making bad choices by
>> preventing them from making any choices is very misguided: If someone
>> thinks $opinion is really the Right Thing To Do[tm], the sensible
>> approach is to try to educate others to help them see the error in their
>> ways, not to force them to pay as little lip service to the superior
>> approach as they're capable of getting away with grudgingly).

>
> As usual, you are accusing me of trying to restrict others' choices,
> when in fact I am simply explaining the reasons for my own.


You wrote

,----
| TT2 allows all those things, with the advantage of not being Turing-
| complete. This may seem like a disadvantage, but it actually makes your
| code much cleaner if you keep the business logic out of the templates
| and allow them to concentrate on presentation.
`----

As it stands, this makes little sense. Because of this, I have chosen to
interpet it as something like "*If* the language used for
HTML-generation is sufficiently complete and easy to use that it can be
used for 'real programming', the end result will likely be
run-of-the-mill PHP-code and this is something one should rather
avoid". I agree with that latter, however, I disagree with the idea that
one would be a 'natural' effect of the other and with the more general
notion that the best way to prevent abuse of features is to remove or
omit them.

If you don't think anyone but you could possibly consider using PHP,
feel free to buy any kind of straight jacket keeping you from it .
 
Reply With Quote
 
Joachim Pense
Guest
Posts: n/a
 
      10-24-2013
Am 24.10.2013 18:23, schrieb Rainer Weikusat:

>
> [Random corollary: It is said that the purpose of Perl would be to make
> the simple things easy and the complicated ones possible. Expanding on
> that, the purpose of a 'web framework' would be to make the simple
> things complicated and relegate the complicated ones to the realm of
> fable.]
>


I wonder if an "HTML disassembler" is available - a program that takes
HTML code as input and produces CGI.pm output.

Joachim
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      10-24-2013
["Followup-To:" header set to comp.lang.perl.misc.]
On 2013-10-24 20:14, Joachim Pense <(E-Mail Removed)> wrote:
> I wonder if an "HTML disassembler" is available - a program that takes
> HTML code as input and produces CGI.pm output.


$/ = undef;
my $html = <STDIN>;
say qq{use CGI;};
say qq{print "Content-Type: text/html; charset=UTF-8\n"};
say qq{print "\n"};
say qq{print <<THE_END_OF_THE_FILE_AS_WE_KNOW_IT};
say $html;
say qq{THE_END_OF_THE_FILE_AS_WE_KNOW_IT};


SCNR,
hp


--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | http://www.velocityreviews.com/forums/(E-Mail Removed) | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      10-25-2013
Joachim Pense <(E-Mail Removed)> writes:
> Am 24.10.2013 18:23, schrieb Rainer Weikusat:
>> [Random corollary: It is said that the purpose of Perl would be to make
>> the simple things easy and the complicated ones possible. Expanding on
>> that, the purpose of a 'web framework' would be to make the simple
>> things complicated and relegate the complicated ones to the realm of
>> fable.]
>>

>
> I wonder if an "HTML disassembler" is available - a program that takes
> HTML code as input and produces CGI.pm output.


I don't think this would be very useful: While this could be used to
reduce the amount of redundant information in the markup, it couldn't
recover semantic information available in the code which generated the
HTML. Eg, another form of the same application is generated by the
following code:

sub form()
{
return ($cgi->start_form(-action => 'vmecs-ctrl.cgi'),

$cgi->table(8, #{border => 1 },

refresh_button(),

$cgi->empty_line(),

vmecs_ctrl_pads()),

$cgi->end_form());
}

vmecs_ctrl_pads is

sub vmecs_ctrl_pads()
{
my @output;

@output = map { vmecs_ctrl_pad($vmecs{$_}); } @vmecs_names;
unless (@output) {
return
$cgi->t_r(
$cgi->td(
$cgi->emph(Lng::str('vmecs_no_vmecs'))));
}

return @output;
}

and vmecs_ctrl_pad is a subroutine returning a list of strings which
make up the HTML for displaying various parameters of 'a vmecs' and some
buttons used to control it.

NB: This is a general problem of 'reverse compilers'. They basically
produce 'assembler code with a different syntax'.
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      10-25-2013
"Peter J. Holzer" <(E-Mail Removed)> writes:
> ["Followup-To:" header set to comp.lang.perl.misc.]
> On 2013-10-24 20:14, Joachim Pense <(E-Mail Removed)> wrote:
>> I wonder if an "HTML disassembler" is available - a program that takes
>> HTML code as input and produces CGI.pm output.

>
> $/ = undef;
> my $html = <STDIN>;
> say qq{use CGI;};
> say qq{print "Content-Type: text/html; charset=UTF-8\n"};
> say qq{print "\n"};
> say qq{print <<THE_END_OF_THE_FILE_AS_WE_KNOW_IT};
> say $html;
> say qq{THE_END_OF_THE_FILE_AS_WE_KNOW_IT};


This is an unrealistic use of sensible high-level language constructs
and a more real-world example could be generated by

printf("print(\"\\Q%s\\E\\n\");\n", $_) for @html;

but while this may be an appropriate representation of someone's idea
of on-the-fly HTML-generation, it doesn't illustrate technical
limitations of the facilities available for doing so.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
(CGI-Target)Could not connect to CGI-Proxy John Smith Java 0 05-15-2006 09:21 PM
Python-cgi or Perl-cgi script doubt praba kar Python 1 07-30-2005 08:25 AM
Python CGI - Accepting Input, Invoking Another Process, Ending CGI LarsenMTL Python 4 11-04-2004 05:59 PM
Calling cgi from cgi thru 'system' function. Different behaviour on browser v/s cmd line Shailan Perl 2 12-15-2003 04:26 PM
Re: CGI Perl "use CGI" statement fail Jürgen Exner Perl 0 07-31-2003 02:00 PM



Advertisments