CGI alternatives/replacements

Discussion in 'Perl Misc' started by Justin C, Dec 15, 2011.

  1. Justin C

    Justin C Guest

    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.

    --
    Justin C, by the sea.
     
    Justin C, Dec 15, 2011
    #1
    1. Advertising

  2. Justin C <> writes:
    > 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'.
     
    Rainer Weikusat, Dec 15, 2011
    #2
    1. Advertising

  3. Justin C

    ccc31807 Guest

    On Dec 15, 10:06 am, Justin C <> wrote:
    > 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 qw:)standard);
    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::print_header(...);
    HTML::print_body($formattedoutput);
    HTML::print_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
     
    ccc31807, Dec 15, 2011
    #3
  4. Justin C

    Steve May Guest

    On 12/15/2011 08:46 AM, Ben Morrow wrote:
    >
    > Quoth Justin C<>:


    <snip>

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

    >
    > 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
     
    Steve May, Dec 15, 2011
    #4
  5. Ben Morrow <> writes:

    [...]

    > 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).
     
    Rainer Weikusat, Dec 16, 2011
    #5
  6. Justin C

    Ted Zlatanov Guest

    On Thu, 15 Dec 2011 22:48:53 +0000 Ben Morrow <> wrote:

    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
     
    Ted Zlatanov, Dec 16, 2011
    #6
  7. Justin C

    Guest

    Justin C <> wrote:
    > 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.
     
    , Dec 17, 2011
    #7
  8. Justin C

    Justin C Guest

    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.

    --
    Justin C, by the sea.
     
    Justin C, Dec 19, 2011
    #8
  9. Justin C

    Ted Zlatanov Guest

    On 17 Dec 2011 03:13:53 GMT 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
     
    Ted Zlatanov, Dec 19, 2011
    #9
  10. Justin C

    Justin C Guest

    On 2011-12-19, Ted Zlatanov <> wrote:
    >
    > 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.

    --
    Justin C, by the sea.
     
    Justin C, Dec 20, 2011
    #10
  11. Ted Zlatanov <> writes:
    > On 17 Dec 2011 03:13:53 GMT 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' ...
     
    Rainer Weikusat, Dec 20, 2011
    #11
  12. Justin C

    Ted Zlatanov Guest

    On Tue, 20 Dec 2011 14:37:56 +0000 Rainer Weikusat <> wrote:

    RW> Ted Zlatanov <> writes:
    >> On 17 Dec 2011 03:13:53 GMT 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.


    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
     
    Ted Zlatanov, Dec 20, 2011
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Bengtsson

    Squezing in replacements into strings

    Peter Bengtsson, Apr 25, 2005, in forum: Python
    Replies:
    3
    Views:
    321
    Peter Bengtsson
    Apr 25, 2005
  2. Claude Henchoz

    URL 'special character' replacements

    Claude Henchoz, Jan 9, 2006, in forum: Python
    Replies:
    6
    Views:
    657
    Claude Henchoz
    Jan 9, 2006
  3. Brian McCullough
    Replies:
    0
    Views:
    507
    Brian McCullough
    Feb 16, 2007
  4. Antoine De Groote
    Replies:
    10
    Views:
    445
    Duncan Booth
    Oct 25, 2006
  5. Replies:
    10
    Views:
    548
    Robert Kern
    Apr 9, 2008
Loading...

Share This Page