Re: Replacement for CGI.pm

Discussion in 'Perl Misc' started by Marius Gavrilescu, Oct 22, 2013.

  1. Bernie Cosell <> 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+ZfMHK69W3y3QDDDrUG31uRDOBLGxj3
    lFC2cW54BF/EKSK23Bha5BFI8P07/5Z5DYzuRj2LzHe3f8Dcvn7HtPYvSgJE5c26
    C38oP66mQQVNtkEWwBbAUoWXTQiHQ0pQA+VmOVOu74X1KO3So7PHodu0zn5ZX8D5
    gh6USsaIpRGiYyqcNQUhuS33h0Pdnid1dGtxiip+EjWe/WW3OB/+EQwrsjZnvMXS
    n1Ji2shwIrumlDyadeToq7ewwDMQmgZ3nKlWIcbJr1jmY+5JTf8EDEiv1tGCx81P
    PlrP+CwQ+O0myrNCGrQXsXZNMa3KcRORUO6gNOeY66tVX8+mnU8jJbhZPTEpgfoA
    ur5TyJjWUaP9K2YzkiAu6IBQqHFCsPp9JsecM89Yjxji6zsOxl87wyaOf1YhcJTu
    67TCtD//jk7PZDKgK37/kMrcufHF2e30CdrJLGgsXyC48brkHYKJ3rkXlWPXP4c9
    wAKNiRoM7QHLmq1jQMcAt+S4aax339dMElZVHhJTO9QnKSbuFx0c6lnJyr50hoEL
    6fBnKYWbOJnX5Ri3Muz9
    =liwd
    -----END PGP SIGNATURE-----
    Marius Gavrilescu, Oct 22, 2013
    #1
    1. Advertising

  2. 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
    Joachim Pense, Oct 22, 2013
    #2
    1. Advertising

  3. Joachim Pense <> 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.
    Rainer Weikusat, Oct 22, 2013
    #3
  4. Marius Gavrilescu

    John Bokma Guest

    Rainer Weikusat <> 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-exchange-for-books.html
    John Bokma, Oct 22, 2013
    #4
  5. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Joachim Pense <> 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 ...
    Rainer Weikusat, Oct 23, 2013
    #5
  6. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> 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 :).
    Rainer Weikusat, Oct 24, 2013
    #6
  7. 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
    Joachim Pense, Oct 24, 2013
    #7
  8. ["Followup-To:" header set to comp.lang.perl.misc.]
    On 2013-10-24 20:14, Joachim Pense <> 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
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Oct 24, 2013
    #8
  9. Joachim Pense <> 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'.
    Rainer Weikusat, Oct 25, 2013
    #9
  10. "Peter J. Holzer" <> writes:
    > ["Followup-To:" header set to comp.lang.perl.misc.]
    > On 2013-10-24 20:14, Joachim Pense <> 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.
    Rainer Weikusat, Oct 25, 2013
    #10
  11. ["Followup-To:" header set to comp.lang.perl.misc.]
    On 2013-10-24 23:39, Ben Morrow <> wrote:
    > Quoth Joachim Pense <>:
    >>
    >> I wonder if an "HTML disassembler" is available - a program that takes
    >> HTML code as input and produces CGI.pm output.

    >
    > Given a single input, Peter's answer is actually the only correct one.


    I don't think so. CGI.pm provides a function for every HTML element, so
    it should be possible to parse an HTML input into a DOM tree and then
    serialize that as nested calls to CGI functions.

    So, this small HTML file:

    <html>
    <head>
    <title>hello</title>
    <link rel="stylesheet" href="hello.css" type="text/css" />
    </head>
    <body>
    <h1>hello, world</h1>
    <p>and goodbye</p>
    </body>
    </html>

    could be converted into:

    html(
    head(
    title('hello'),
    Link({-rel => 'stylesheet', type => 'text/css', -href => 'hello.css'}),
    ),
    body(
    h1('hello, world'),
    p('and goodbye')
    )
    )

    I think this is what Joachim meant.

    I just don't think that would be terribly useful. But then I think the
    html-generating functions in CGI.pm aren't very useful in general, so
    that't not a big surprise ;-).

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Oct 26, 2013
    #11
  12. "Peter J. Holzer" <> writes:
    > ["Followup-To:" header set to comp.lang.perl.misc.]
    > On 2013-10-24 23:39, Ben Morrow <> wrote:
    >> Quoth Joachim Pense <>:
    >>>
    >>> I wonder if an "HTML disassembler" is available - a program that takes
    >>> HTML code as input and produces CGI.pm output.

    >>
    >> Given a single input, Peter's answer is actually the only correct one.

    >
    > I don't think so. CGI.pm provides a function for every HTML element, so
    > it should be possible to parse an HTML input into a DOM tree and then
    > serialize that as nested calls to CGI functions.
    >
    > So, this small HTML file:
    >
    > <html>
    > <head>
    > <title>hello</title>
    > <link rel="stylesheet" href="hello.css" type="text/css" />
    > </head>
    > <body>
    > <h1>hello, world</h1>
    > <p>and goodbye</p>
    > </body>
    > </html>
    >
    > could be converted into:
    >
    > html(
    > head(
    > title('hello'),
    > Link({-rel => 'stylesheet', type => 'text/css', -href => 'hello.css'}),
    > ),
    > body(
    > h1('hello, world'),
    > p('and goodbye')
    > )
    > )
    >
    > I think this is what Joachim meant.
    >
    > I just don't think that would be terribly useful.


    As I already wrote elsewhere: 'Reverse-compiling' some generated code is
    never very useful. But this had already turned the unstructured HTML
    character stream into a structured equivalent (albeit a poorly
    structured one), reduced the amount of text by about 50% and enabled
    future changes with less work and less chances for errors, eg, someone
    could change the h1 to a h2 by changing a single character and the
    correct end tag would be generated automatically.

    Things become a little more interesting when realizing that this is
    actually a functional/ applicative program because it doesn't have to
    print something as a side effect but could return a list of string
    instead.
    Rainer Weikusat, Oct 26, 2013
    #12
  13. Ben Morrow <> writes:
    > Quoth "Peter J. Holzer" <>:


    [...]

    >> So, this small HTML file:
    >>
    >> <html>
    >> <head>

    > [...]
    >>
    >> could be converted into:
    >>
    >> html(
    >> head(

    > [...]


    [...]

    >> I just don't think that would be terribly useful. But then I think the
    >> html-generating functions in CGI.pm aren't very useful in general, so
    >> that't not a big surprise ;-).

    >
    > Well, if one is using the HTML-generating functions, it might be
    > useful.


    NB: The text below is firmly based on ignoring the somewhat persistent
    failures of the W3C to prevent HTML from being useful as general way to
    describe graphical user interfaces in favour of producing a myriad of
    mutually incompatible 'standards' to accomplish the same thing in as
    many different way, all of which are either deprecated, incomplete or
    without sufficient support across a range of common browsers to be
    useful. Considering that Microsoft is a major sponsor of this
    organization, this might as well just be an implementation the
    'original' Microsoft-vs-Netscape strategy [If you're blind, GUIs are
    obviously not for you and that's that].

    It is possible to define a general 'tag function' which behaves as
    follows: The first argument can be a hash reference. In this case, the
    hash contains tag attributes. An arbitrary number of other arguments can
    follow. The tag function returns a string describing the 'open' tag with
    added attributes as required, following by all of its 'list arguments',
    followed by the a string representing the closing tag. If no special
    processing is required, tag-functions are generated via AUTOLOAD. It
    might make sense to use a single subroutine created in a suitable
    lexical environment instead of creating a large number of different
    subroutines with almost identical code. A toy example of that coud look
    like this (toy example because it doesn't deal with encoding 'special
    characters'):

    ------------
    package Tag;

    sub AUTOLOAD {
    our $AUTOLOAD;
    my $tag;

    $AUTOLOAD =~ /^.*::([^:]+)/ and $tag = $1;
    *$AUTOLOAD = sub {
    my @attrs;

    if (ref($_[0]) eq 'HASH') {
    @attrs = map { $_.'="'.$_[0]->{$_}.'"' } keys(%{$_[0]});
    shift;
    }

    return ("<$tag ".join(' ', @attrs).'>',
    @_,
    "</$tag>");
    };

    goto &$AUTOLOAD;
    }

    package main;

    print(join("\n", Tag::body({bgcolor => 'white', color=> 'blue'}, 'Text')), "\n");
    ------------

    Something mildy more interesting can be done with an additional function
    merging two hashes:

    sub merge_attrs
    {
    my %attrs;

    %attrs = %{$_[0]};
    $attrs{$_} = $_[1]->{$_} for keys(%{$_[1]});
    return \%attrs;
    }

    because this enables defining tag functions supplying some set of
    overridable/ expandle default attributes:

    -----------
    package Std;

    sub merge_attrs
    {
    my %attrs;

    %attrs = %{$_[0]};
    $attrs{$_} = $_[1]->{$_} for keys(%{$_[1]});
    return \%attrs;
    }

    sub table
    {
    my $attrs = {cellspacing => 0, cellpadding => 0};

    $attrs = merge_attrs($attrs, shift) if ref($_[0]) eq 'HASH';
    return Tag::table($attrs, @_);
    }

    package main;

    print(join("\n",
    Tag::body({bgcolor => 'white', color=> 'blue'},
    Std::table({border => 1},
    Tag::tr(
    Tag::td('Blah'))))));
    -----------

    These 'default-attribute-supplying tag functions' could also be
    auto-generated:

    ------------
    package Std;

    sub merge_attrs
    {
    my %attrs;

    %attrs = %{$_[0]};
    $attrs{$_} = $_[1]->{$_} for keys(%{$_[1]});
    return \%attrs;
    }

    sub make_def_tag
    {
    my $def_attrs = $_[0];
    my $tagf = $_[1];

    return sub {
    my $attrs = $def_attrs;
    $attrs = merge_attrs($attrs, shift) if ref($_[0]) eq 'HASH';
    $tagf->($attrs, @_);
    };
    }

    *table = make_def_tag({cellspacing => 0, cellpadding => 0}, \&Tag::table);

    package main;

    *btable = Std::make_def_tag({border => 1}, \&Std::table);

    print(join("\n",
    Tag::body({bgcolor => 'white', color=> 'blue'},
    btable({cellpadding => 5},
    Tag::tr(
    Tag::td('Blah'))))));
    ------------

    NB: This is a (n executable) sketch showing how to build higher-level
    abstractions closer to the problem domain from the ground
    up. Necessarily, since this is a made-up example, it remains pretty
    low-level.

    > One of the reasons I don't use them is because of the work involved in
    > translating a static HTML page into an equivalent list of function
    > calls.


    Where did the static HTML-page come from? A stranger slipped it through
    below you door in 1823 and you've been using it ever since? It was
    hammered in stone based on direct instruction from above given atop of a
    mountain the middle-east in ancient times? Or could it be that you wrote
    it prior to implementing the 'active' parts of your wepplication?
    Rainer Weikusat, Oct 27, 2013
    #13
  14. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> writes:
    >> >
    >> > Well, if one is using the HTML-generating functions, it might be
    >> > useful.

    >>

    > [...]
    >> It is possible to define a general 'tag function' which behaves as
    >> follows: The first argument can be a hash reference. In this case, the
    >> hash contains tag attributes.

    > [...]
    >>
    >> Something mildy more interesting can be done with an additional function
    >> merging two hashes:

    > [...]
    >> because this enables defining tag functions supplying some set of
    >> overridable/ expandle default attributes:

    >
    > Yes, that's all true, and when we were generating HTML 3.2, with its
    > horribly limited attribute-based formatting, that sort of thing would
    > have been very useful. (Presumably that's why CGI.pm acquired these
    > functions in the first place.)


    'Presumably', CGI.pm 'acquired these functions in the first place' (and
    I wasn't writing about the CGI.pm functions) because a CGI-program will
    usually involve dynamically generated HTML in order to interact with a
    user and one way to do this easily is to use a the facilities of a
    programming language in order to generate it.

    It is no small wonder that people who feel very much out home inside
    their WYSIWYG HTML-editors and seriously uncomfortable with
    non-interactive, higher-level abstracting programmable ways to
    accomplish the same task don't understand why this would be useful and
    this is no different today than it was in 1995. But (imagine this) not
    everybody on this planet is 'a reluctant programmer' forced to write
    code because there's really no other way.
    Rainer Weikusat, Oct 27, 2013
    #14
  15. Ben Morrow <> writes:
    > Quoth Rainer Weikusat <>:
    >> Ben Morrow <> writes:
    >> >
    >> > Well, if one is using the HTML-generating functions, it might be
    >> > useful.

    >>

    > [...]
    >> It is possible to define a general 'tag function' which behaves as
    >> follows: The first argument can be a hash reference. In this case, the
    >> hash contains tag attributes.

    > [...]
    >>
    >> Something mildy more interesting can be done with an additional function
    >> merging two hashes:

    > [...]
    >> because this enables defining tag functions supplying some set of
    >> overridable/ expandle default attributes:

    >
    > Yes, that's all true, and when we were


    [...]

    IMHO, this is a flamebait I'm going to ignore because of that.
    Rainer Weikusat, Oct 27, 2013
    #15
  16. Rainer Weikusat <> writes:
    > Ben Morrow <> writes:
    >> Quoth Rainer Weikusat <>:
    >>> Ben Morrow <> writes:
    >>> >
    >>> > Well, if one is using the HTML-generating functions, it might be
    >>> > useful.
    >>>

    >> [...]
    >>> It is possible to define a general 'tag function' which behaves as
    >>> follows: The first argument can be a hash reference. In this case, the
    >>> hash contains tag attributes.

    >> [...]
    >>>
    >>> Something mildy more interesting can be done with an additional function
    >>> merging two hashes:

    >> [...]
    >>> because this enables defining tag functions supplying some set of
    >>> overridable/ expandle default attributes:

    >>
    >> Yes, that's all true, and when we were

    >
    > [...]
    >
    > IMHO, this is a flamebait I'm going to ignore because of that.


    Except this: Considering what I know about (X)HTML generated by JSF and
    RichFaces (both 'state of the art, enterprise-grade HTML generation
    toolkits/ frameworks'), the statement that 'nowadays, we use
    attribute-free hand-written HTML5 formatted only via CSS' must have been
    made by some guy living on a different planet: Maybe, some people do
    that, but it certainly isn't the norm for web GUIs, which are rather
    centered around "use bits and pieces of everything" (favoring more
    conservative approaches over more modern ones where possible) _provided
    the result works_.
    Rainer Weikusat, Oct 27, 2013
    #16
  17. Marius Gavrilescu

    Marc Espie Guest

    In article <>,
    Peter J. Holzer <> wrote:
    >["Followup-To:" header set to comp.lang.perl.misc.]
    >On 2013-10-24 23:39, Ben Morrow <> wrote:
    >> Quoth Joachim Pense <>:
    >>>
    >>> I wonder if an "HTML disassembler" is available - a program that takes
    >>> HTML code as input and produces CGI.pm output.

    >>
    >> Given a single input, Peter's answer is actually the only correct one.

    >
    >I don't think so. CGI.pm provides a function for every HTML element, so
    >it should be possible to parse an HTML input into a DOM tree and then
    >serialize that as nested calls to CGI functions.
    >
    >So, this small HTML file:
    >
    > <html>
    > <head>
    > <title>hello</title>
    > <link rel="stylesheet" href="hello.css" type="text/css" />
    > </head>
    > <body>
    > <h1>hello, world</h1>
    > <p>and goodbye</p>
    > </body>
    > </html>
    >
    >could be converted into:
    >
    > html(
    > head(
    > title('hello'),
    > Link({-rel => 'stylesheet', type => 'text/css', -href =>
    >'hello.css'}),
    > ),
    > body(
    > h1('hello, world'),
    > p('and goodbye')
    > )
    > )
    >
    >I think this is what Joachim meant.
    >
    >I just don't think that would be terribly useful. But then I think the
    >html-generating functions in CGI.pm aren't very useful in general, so
    >that't not a big surprise ;-).


    You could probably do that using the HTML::Tree parser and then writing
    a proper printer...

    Chiming in a bit late in the discussion, CGI.pm is terrible terrible for
    anything facing the internet in general. Good luck sanitizing any kind
    of input, or quoting stuff correctly in the generated html.

    That's one area where template systems like TT shine, they have everything
    needed to enlighten you to the multiple problems properly encoding stuff
    to write non-broken pages with no XSS issues...

    (big fan of perl-dancer + template toolkit these days... the RESTful nature
    of the engine being a big plus)
    Marc Espie, Jan 23, 2014
    #17
  18. (Marc Espie) writes:

    [...]

    > Chiming in a bit late in the discussion, CGI.pm is terrible terrible for
    > anything facing the internet in general. Good luck sanitizing any kind
    > of input, or quoting stuff correctly in the generated html.


    That this is something you consider an almost insurmountable obstacle
    doesn't mean everybody shares your opinion on that.
    Rainer Weikusat, Jan 23, 2014
    #18
    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. Jürgen Exner

    Re: CGI Perl "use CGI" statement fail

    Jürgen Exner, Jul 31, 2003, in forum: Perl
    Replies:
    0
    Views:
    1,250
    Jürgen Exner
    Jul 31, 2003
  2. Peter Makholm

    Re: Replacement for CGI.pm

    Peter Makholm, Oct 22, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    126
    Peter Makholm
    Oct 22, 2013
  3. Rainer Weikusat

    Re: Replacement for CGI.pm

    Rainer Weikusat, Oct 22, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    142
    Rainer Weikusat
    Oct 22, 2013
  4. Xho Jingleheimerschmidt

    Re: Replacement for CGI.pm

    Xho Jingleheimerschmidt, Oct 23, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    124
    Xho Jingleheimerschmidt
    Oct 23, 2013
  5. George Mpouras

    Re: Replacement for CGI.pm

    George Mpouras, Oct 23, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    127
    George Mpouras
    Oct 23, 2013
Loading...

Share This Page