CGI alternatives/replacements

[Justin C]

I visited a perl irc channel recently to try to get a quick answer to a
problem, the solution was found eventually. Part of the discussion led
to the suggestion that I shouldn't be using CGI.pm, but one of the web
frameworks: Catalyst, CGI::Application, Jifty, Continuity, Mojolicious,
Dancer, etc.

I don't find irc the best medium for a decent discussion, it's not easy
for people to reply with well considered thoughts, just snippets and
sound-bites, so I thought I'd ask about these web-frameworks here.

Has CGI.pm come to the end of it's usefulness? The company intranet site
has about a dozen or so pages, a couple of them static HTML ... but
using CGI to ensure consistent styling (CGI does the start and end html
stuff, between that is sub that opens the page body and prints that to
the browser). I can see that if I were to start this task again I would
do it differently, perhaps use a web-app, and the whole site driven by
one cgi - instead of clicking a link for, say, prospect management and
being taken to a page that actually manages that, having the web-app
return the functions needed for that choice. At least, that's what I
understand these frameworks to enable, and how the web-apps work.

Have I got that right? I know TMTOWTDI, but what is the 'usual' way
these days?

Justin.

 

[Rainer Weikusat]

I visited a perl irc channel recently to try to get a quick answer to a
problem, the solution was found eventually. Part of the discussion led
to the suggestion that I shouldn't be using CGI.pm, but one of the web
frameworks: Catalyst, CGI::Application, Jifty, Continuity, Mojolicious,
Dancer, etc.

I don't find irc the best medium for a decent discussion, it's not easy
for people to reply with well considered thoughts, just snippets and
sound-bites, so I thought I'd ask about these web-frameworks here.

I think you have answered your own question: These frameworks are
'marketed' by people who cannot (and couldn't care less for)
expressing their own thoughts in a consistent and clear way. That's a
large grain of salt going with their 'opinions'.

 

[ccc31807]

Has CGI.pm come to the end of it's usefulness?

I've used CGI.pm since around 1999 to build many web sites. In the
past several years, I've used it extensively at work to build
graphical interfaces to databases. FWIW, here's my opinion.

I have never, repeat never, used CGI to construct outgoing HTML. I
write the HTML by hand, typically putting it into a module in the
application directory named HTML.pm, and write the HTML fragments
using qq(), here docs, or similar, sometimes just using print(). I
started doing this in the beginning because I was frustrated
integrating CSS and JavaScript with CGI, and it was just easier for me
to do it this way.

For my database connections, I typically write a module called SQL.pm,
and call that as well. For the programmatic aspects, I write a module
named after the application, and call that as well.

I have never used anything other than CGI to handle HTTP requests in
my scripts, and I've never had a complaint.

My web apps wind up looking a lot like this:

use strict;
use warnings;
use CGI qwstandard);
use CGI::Carp qw(fatalsToBrowser);
use HTML;
use SQL;
use APP; #this is my program code
use DBI: #if needed
use Mail::Sendmail #if needed
use MIME::Lite #if needed
use PDF::API2 #if needed
....
my $what = param('what');
....
elsif($what eq 'Request Employee Data')
{
my $queryresults = SQL::employee_select($what); #returns hash ref
my $returnvalues = APP::employee_select($queryresults); #builds data
my $formattedoutput = HTML::employee_select($returnvalues); #returns
HTML as a string
}
....
else { $formattedoutput = HTML::default_page(); } #user didn't make
any request
#main logic
HTML:rint_header(...);
HTML:rint_body($formattedoutput);
HTML:rint_footer(...);
exit(0);

Obviously, there are better ways to do this, using dispatch tables is
one that I am presently experimenting with, but this has worked well
for me in that it's conceptually simple, easy to write, easy to
maintain, modular, and reliable.

Monday of this week, I bashed out a web app in about eight hours
(using SQLite) mostly without having to refer to any documentation,
using exactly this kind of structure. If you do it a lot, as I have,
you can do it with your eyes closed. I'm sure that a seasoned .NET
programmer using Visual Studio could probably do it in half the time,
but the typical PHP or ColdFusion guy would take twice as long, and
IMO Perl/CGI beats them all for cost, reliability, and simplicity.

CC

 

[Steve May]

Quoth Justin C<[email protected]>:


For a larger job (anything that might reasonably be called an
'application'), I would use Catalyst, because I know it and it works
extremely well. I believe Dancer and Mojo are supposed to be lighter-
weight alternatives, in that it takes less time and less code to get to
a working app, but I haven't used them.

For small jobs, the sort that might once have been written as a single
CGI script, I quite like using Plack::{Request,Response} directly. The
documentation says they're too low-level for app code to use, and that
is true to an extent, but if you just want to do one small job that
hardly matters.

I've been fooling around with cgi scripts for years, and though I've
played with Catalyst I've yet to construct more than simple test apps.

The learning curve is a bit steep and I'm still getting a handle on
using and deploying it, but Catalyst *is* delightfully perlish compared
to the Rails straight jacket.

I already owe you a Pint for your post, but just out of curiosity, could
you indulge me by passing on your thoughts on what constitutes "anything
that might reasonably be called an 'application'"


TIA,

Steve

 

[Rainer Weikusat]

[...]

There are two entirely separate questions here:

- How does my program receive requests from, ultimately, the user's
browser?

- How do I construct my responses?

You can use CGI.pm for both of these, or you can use it for one and not
the other, or you can use it for neither.

With regards to the second (constructing responses), I would never
recommend anyone use the functions in CGI.pm. It is far cleaner to keep
your HTML/CSS/JS/whatever separate from your Perl.
Personally I would use
[...]

Other people may use other solutions:
[...]

Any of these solutions is, IMHO, better than putting
HTML-generating code in with your main program logic.

Provided the HTML-generating code is sufficiently complicated enough
that moving it out of focus actually buys something and is not just an
encumbrance, it can always be moved to a different file without also
moving it to a different language. And with a relatively tiny amount
of abstraction, 'HTML-generating code' can easily look like this:


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)),

$cgi->empty_line(),

$cgi->flush_right(3,
param('mac_addr', MAC_LEN)),
$cgi->flush_right(3,
$cgi->expln(Lng::str('vmecs_optional'))),

$cgi->empty_line(),

$cgi->flush_right(3,
$cgi->titled_cell(Lng::str('vmecs_start_now'),
checkbox('start'))),

$cgi->empty_line(),

buttons()),

$cgi->end_form(), "\n");
}
[(c) my employer, quoted for educational purposes]
(no, I don't care for the random W3C standard of the day)

[...]

As for the first question (receiving requests), using genuine unmodified
CGI (with a fresh invocation of perl per request) is quite rare
nowadays. It's considered to be extremely inefficient, especially since
modern Perl style tends towards using lots of modules, many of which
tend to take a long time (relatively speaking) to load.

Funny as it may seem, this 'extremely inefficient solution' (meaning,
doing a fork-and-exec per invocation) was efficient enough for being
used on hardware which was much feebler than what is used for a
present-day smartphones. This implies that it really ought to be much
more widely applicable than it was fifteen years ago. The amount of
code which needs to be compiled being orders of magnitude larger
than the amount of code which is actually used would be a design
problem. And there is nothing 'modern' in the "I'll what I can
download for free on the internet and glue that together somehow,
technically sensible soluting be damned, I can't program!" approach to
solving a problem: That's what some people have been doing ever since
the option became available. In a different context, there's a German
verb for this activity, namely 'abschreiben' (I would wager a bet that
the sets of people clinging to either 'problem solving methodology'
are more or less identical).

 

[Ted Zlatanov]

BM> My understanding is that this is exactly what 'lighter' frameworks like
BM> Mojo and Dancer are supposed to address: getting to 'hello world' is
BM> meant to be much quicker. I rather suspect that on a project of any size
BM> the complexity has to go somewhere, and it just ends up finding its way
BM> in later, but I've never used them in anger so I don't know.

I've been very happy and productive lately using CouchDB and couch apps
to host all the content without any CGI interactions. For a certain
application domain, it's a very nice lightweight approach and the
built-in replication doesn't hurt. Plus Perl plays very nicely with
JSON content and there are plenty of modules for CouchDB interaction
(AnyEvent::CouchDB is my favorite).

In the Perl world, I really like Dancer and Mojolicious. Simple things
made simple.

Ted

 

[xhoster]

I visited a perl irc channel recently to try to get a quick answer to a
problem, the solution was found eventually. Part of the discussion led
to the suggestion that I shouldn't be using CGI.pm, but one of the web
frameworks: Catalyst, CGI::Application, Jifty, Continuity, Mojolicious,
Dancer, etc.

I don't find irc the best medium for a decent discussion, it's not easy
for people to reply with well considered thoughts, just snippets and
sound-bites, so I thought I'd ask about these web-frameworks here.

Has CGI.pm come to the end of it's usefulness?

Not for me.

The company intranet site
has about a dozen or so pages, a couple of them static HTML ... but
using CGI to ensure consistent styling (CGI does the start and end html
stuff, between that is sub that opens the page body and prints that to
the browser). I can see that if I were to start this task again I would
do it differently, perhaps use a web-app, and the whole site driven by
one cgi - instead of clicking a link for, say, prospect management and
being taken to a page that actually manages that, having the web-app
return the functions needed for that choice. At least, that's what I
understand these frameworks to enable, and how the web-apps work.

I don't see the advantage of having a single CGI do a bunch of unrelated
stuff. That seems like a disadvantage to me.

Have I got that right? I know TMTOWTDI, but what is the 'usual' way
these days?

If you want to spend 5 minutes writing a new form, and have it look like it
was written in 5 minutes, I'd stick with CGI.pm. If you want your forms to
look like they were designed by a professional graphics artist with a lot
of time on their hands (and are actually willing to hire one to spend that
time!) then I certainly wouldn't CGI.pm, although I don't exactly what to
recommend instead.

I'm from the get-er-done school myself.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

 

[Justin C]

Thank you Ben, and everyone for the interesting posts. I'll do some
reading up on PSGI, Plack and Catalyst.

I do know that every time I review code I've written more than about 6
months ago I realise that I've learnt a better way to do a whole bunch
of it, and often re-write. Maybe the next time I rewrite any of the
intranet pages I'll consider a migration and do one part at a time.

It's been very interesting reading your replies, thank you again.

Justin.

 

[Ted Zlatanov]

On 17 Dec 2011 03:13:53 GMT (e-mail address removed) wrote:

x> If you want your forms to look like they were designed by a
x> professional graphics artist with a lot of time on their hands (and
x> are actually willing to hire one to spend that time!) then I
x> certainly wouldn't CGI.pm, although I don't exactly what to recommend
x> instead.

If you want nice forms and HTML in general with minimum effort, use
Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
concentrate on the data handling. There are some Javascript plugins but
they are not required. That will let you put off hiring a graphics
designer for a bit longer

Ted

 

[Justin C]

If you want nice forms and HTML in general with minimum effort, use
Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
concentrate on the data handling. There are some Javascript plugins but
they are not required. That will let you put off hiring a graphics
designer for a bit longer

Thank you for the pointer. Interesting stuff. Our site is already quite
tightly designed, but I have a use for this outside work.

Justin.

 

[Rainer Weikusat]

On 17 Dec 2011 03:13:53 GMT (e-mail address removed) wrote:

x> If you want your forms to look like they were designed by a
x> professional graphics artist with a lot of time on their hands (and
x> are actually willing to hire one to spend that time!) then I
x> certainly wouldn't CGI.pm, although I don't exactly what to recommend
x> instead.

If you want nice forms and HTML in general with minimum effort, use
Blueprint CSS (from Twitter). It does all the visuals in CSS so you can
concentrate on the data handling. There are some Javascript plugins but
they are not required.

.... provided that compatibility with existing client software, aka
'Javascript browser detection' in order to work around the fact that
no software on this planet supports anything the W3C specified in the
last 20 years completely, not the least because the W3C usually comes
up with five different way to solve the same problem in half as many
years, is also 'not required' ...

 

[Ted Zlatanov]

x> If you want your forms to look like they were designed by a
x> professional graphics artist with a lot of time on their hands (and
x> are actually willing to hire one to spend that time!) then I
x> certainly wouldn't CGI.pm, although I don't exactly what to recommend
x> instead.
RW> ... provided that compatibility with existing client software, aka
RW> 'Javascript browser detection' in order to work around the fact that
RW> no software on this planet supports anything the W3C specified in the
RW> last 20 years completely, not the least because the W3C usually comes
RW> up with five different way to solve the same problem in half as many
RW> years, is also 'not required' ...

Right. Exactly. You read my mind. It's like we're twins.

Ted