in reply to br tag in CGI.pm V2.91

perl -MCGI=br -e die(br) <br /> at -e line 1.
I am personally beginning to hate CGI.pm, cause with every new version more bugs crop up. I've cut back on using the html generation shortcuts except for one-off scripts, and I am beginning to completely phase out all usage of CGI.pm.


MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: br tag in CGI.pm V2.91
by Ovid (Cardinal) on Apr 10, 2003 at 15:50 UTC

    Out of curiosity, what are you using in place of it? There are decent alternatives out there and I'm curious to know which you chose and why.

    Cheers,
    Ovid

    New address of my CGI Course.
    Silence is Evil (feel free to copy and distribute widely - note copyright text)

      Well, Apache::Request wherever available (obvious reasons), and CGI::Simple (despite a few minor annoyances relating to VERSION).

      CGI::Simple well tested and lightweight, and will soon be improving (i hope) to handle mod_perl without work on the programmers part (delete __DATA__/use SelfLoader; is not cool)

      The only other decent alternative "might" be CGI-Minimal, but I won't even consider it due to the sorry state of affairs that the test suite is (when that situation improves, i'll give it a closer look).

      And before you say CGI-Thin, that thing's got too many bugs pending.

      I really do feel we need a pure-perl CGI module akin to Apache::Request that is well written.

      How about you?


      MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
      I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
      ** The Third rule of perl club is a statement of fact: pod is sexy.

        A pure Perl version of Apache::Request? If Apache::Request is well-written, why bother with the Pure Perl version? Aside from making it easier for poor schleps to modify it, that is? :)

        I was looking in apache_request.c and noticed this, though:

        static int urlword_dlm[] = {'&', ';', 0}; static char *my_urlword(pool *p, const char **line) { char *res = NULL; const char *pos = *line; char ch; while ( (ch = *pos) != '\0' && ch != ';' && ch != '&') { ++pos; } res = ap_pstrndup(p, *line, pos - *line); while (ch == ';' || ch == '&') { ++pos; ch = *pos; } *line = pos; return res; }

        The urlword_dlm array doesn't appear to be used anywhere else. From what I can tell, this was originally used to hold the delimiters and line endings, but when the code was last updated, the array declaration was left in, but the array itself appears to have been removed:

        static int urlword_dlm[] = {'&', ';', NULL}; static char *my_urlword(pool *p, const char **line) { int i; for (i = 0; urlword_dlm[i]; i++) { int stop = urlword_dlm[i]; char *pos = strchr(*line, stop); char *res; if (!pos) { if (!urlword_dlm[i+1]) { // etc ...

        That could simply be my poor C skills, but it looks like there might be some room for cruft to be removed (of course, this was the only instance I found, so I'm probably wrong), so I wonder if there is room for improvement here. In any event, since Apache::Request can be used from both C and Perl, I don't think that creating a Perl alternative gets us a strong benefit. I'm open to counter arguments, though.

        And I'd just like to note that my little digression there was soooo far removed from your question that my li'l node is barely a response :)

        Cheers,
        Ovid

        New address of my CGI Course.
        Silence is Evil (feel free to copy and distribute widely - note copyright text)