arrange form data in same order as on form

Discussion in 'Perl Misc' started by bbxrider, Nov 13, 2003.

  1. bbxrider

    bbxrider Guest

    is there a way to sort (or other method) the 'method=post' data fields from
    a form into
    the same order they appear in the form
    when i use the following code there doesn't appear to be any particular
    order to how they are arranged

    read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    @pairs = split(/&/, $buffer);
    foreach $pair (@pairs) {
    ($name, $value) = split(/=/, $pair);
    $value =~ tr/+/ /;
    $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    $FORM{$name} = $value;
     
    bbxrider, Nov 13, 2003
    #1
    1. Advertising

  2. bbxrider

    Ben Morrow Guest

    "bbxrider" <> wrote:
    > is there a way to sort (or other method) the 'method=post' data fields from
    > a form into
    > the same order they appear in the form
    > when i use the following code there doesn't appear to be any particular
    > order to how they are arranged
    >
    > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    > @pairs = split(/&/, $buffer);
    > foreach $pair (@pairs) {
    > ($name, $value) = split(/=/, $pair);
    > $value =~ tr/+/ /;
    > $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    > $FORM{$name} = $value;


    Firstly, you *really* should be using CGI or CGI::Lite rather than
    parsing stdin yourself.

    If the browser doesn't return them in order, then the only way to put
    them back in order is to know what order they were in on the original
    form. One way of doing this might be to give them names beginning with
    '01', '02' etc.: if you generate the form yourself you can automate
    this.

    Note that hashes are inherently unordered: if you create a hash with
    more than one key there is *no* guarantee about the order you will get
    the keys back in when you list them. If you need there to be, then
    either keep a separate array of keys to hold the order, or use
    Tie::IxHash from CPAN which does that for you.

    Ben

    --
    $.=1;*g=sub{print@_};sub r($$\$){my($w,$x,$y)=@_;for(keys%$x){/main/&&next;*p=$
    $x{$_};/(\w)::$/&&(r($w.$1,$x.$_,$y),next);$y eq\$p&&&g("$w$_")}};sub t{for(@_)
    {$f&&($_||&g(" "));$f=1;r"","::",$_;$_&&&g(chr(0012))}};t #
    $J::u::s::t, $a::n::eek:::t::h::e::r, $P::e::r::l, $h::a::c::k::e::r, $.
     
    Ben Morrow, Nov 13, 2003
    #2
    1. Advertising

  3. "bbxrider" <> wrote in
    news:7cUsb.139690$mZ5.963708@attbi_s54:

    > is there a way to sort (or other method) the 'method=post' data
    > fields from a form into the same order they appear in the form
    > when i use the following code there doesn't appear to be any
    > particular order to how they are arranged


    why do you care?

    > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    > @pairs = split(/&/, $buffer);


    this code is buggy. either write your own, taking into account all the fine
    points of the specs, or just use CGI.pm. but don't use someone else's buggy
    code.

    Sinan.

    --
    A. Sinan Unur

    Remove dashes for address
    Spam bait: mailto:
     
    A. Sinan Unur, Nov 13, 2003
    #3
  4. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    "bbxrider" <> wrote in
    news:7cUsb.139690$mZ5.963708@attbi_s54:

    > is there a way to sort (or other method) the 'method=post' data
    > fields from a form into
    > the same order they appear in the form
    > when i use the following code there doesn't appear to be any
    > particular order to how they are arranged


    The CGI spec does not guarantee that the form variables will be submitted
    in any particular order, so you're out of luck.

    > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    > @pairs = split(/&/, $buffer);
    > foreach $pair (@pairs) {
    > ($name, $value) = split(/=/, $pair);
    > $value =~ tr/+/ /;
    > $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    > $FORM{$name} = $value;


    This is exceedingly bad code. Unless you really know what you're doing,
    and have strong reasons not to, you should use the CGI module.

    We keep seeing this exact same bad code posted to this newsgroup. Out of
    curiosity, where did you copy it from?

    - --
    Eric
    $_ = reverse sort $ /. r , qw p ekca lre uJ reh
    ts p , map $ _. $ " , qw e p h tona e and print

    -----BEGIN PGP SIGNATURE-----
    Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

    iQA/AwUBP7Qbf2PeouIeTNHoEQKb6gCfbgrhGAcLpyRLTC5cUW4U1AsVIsQAn3Ev
    bAiVGyJb/3J4v/fhU4Yi9w1q
    =vDoO
    -----END PGP SIGNATURE-----
     
    Eric J. Roode, Nov 14, 2003
    #4
  5. A. Sinan Unur wrote:
    > "bbxrider" <> wrote in
    > news:7cUsb.139690$mZ5.963708@attbi_s54:
    >
    >>read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    >>@pairs = split(/&/, $buffer);

    >
    > this code is buggy.


    Do you know the context in which that code is used? If not, you can't
    reasonably tell whether it's "buggy".

    > either write your own, taking into account all the fine
    > points of the specs,


    That's important only if you are writing a general purpose function or
    module. What makes you think that that is what OP is about to do?

    > or just use CGI.pm.


    That is one option.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Nov 14, 2003
    #5
  6. bbxrider

    Ben Morrow Guest

    Gunnar Hjalmarsson <> wrote:
    > A. Sinan Unur wrote:
    > > "bbxrider" <> wrote in
    > > news:7cUsb.139690$mZ5.963708@attbi_s54:
    > >
    > >>read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    > >>@pairs = split(/&/, $buffer);

    > >
    > > this code is buggy.

    >
    > Do you know the context in which that code is used? If not, you can't
    > reasonably tell whether it's "buggy".


    The OP is attempting to interpret a CGI POST request, as stated in the
    Original Post.

    > > either write your own, taking into account all the fine
    > > points of the specs,

    >
    > That's important only if you are writing a general purpose function or
    > module. What makes you think that that is what OP is about to do?


    It is important in all circumstances where the data being received is
    not entirely under your control; eminently the case in a CGI
    environment.

    > > or just use CGI.pm.

    >
    > That is one option.


    ....and by far the best[1], unless you are (a) very clever and (b) need to
    do something particular that CGI.pm doesn't do for you.

    The whole *point* of CPAN is so that people don't have to keep failing
    to solve the same difficult problems over and over again.

    Ben

    [1] modulo equivalent alternatives, such as CGI::Lite.

    --
    Like all men in Babylon I have been a proconsul; like all, a slave ... During
    one lunar year, I have been declared invisible; I shrieked and was not heard,
    I stole my bread and was not decapitated.
    ~ ~ Jorge Luis Borges, 'The Babylon Lottery'
     
    Ben Morrow, Nov 14, 2003
    #6
  7. Ben Morrow wrote:
    > Gunnar Hjalmarsson wrote:
    >> A. Sinan Unur wrote:
    >>> bbxrider wrote:
    >>>>
    >>>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); @pairs =
    >>>> split(/&/, $buffer);
    >>>
    >>> this code is buggy.

    >>
    >> Do you know the context in which that code is used? If not, you
    >> can't reasonably tell whether it's "buggy".

    >
    > The OP is attempting to interpret a CGI POST request, as stated in
    > the Original Post.


    I meant context in a more narrow sense, of course.

    Still don't understand what it is that makes the above code "buggy".

    >>> either write your own, taking into account all the fine points
    >>> of the specs,

    >>
    >> That's important only if you are writing a general purpose
    >> function or module. What makes you think that that is what OP is
    >> about to do?

    >
    > It is important in all circumstances where the data being received
    > is not entirely under your control; eminently the case in a CGI
    > environment.


    What's important in those circumstances is that you validate the data
    properly, run the program in taint mode, etc. Using CGI.pm does not
    take care of everything, right?

    >>> or just use CGI.pm.

    >>
    >> That is one option.

    >
    > ...and by far the best[1], unless you are (a) very clever and (b)
    > need to do something particular that CGI.pm doesn't do for you.
    >
    > The whole *point* of CPAN is so that people don't have to keep
    > failing to solve the same difficult problems over and over again.


    I'm not questioning the advantages with code reuse in general. I'm
    just (once again) reacting to the aggressive way, sometimes not to the
    point, in which some people here argue for using CGI.pm.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Nov 14, 2003
    #7
  8. Gunnar Hjalmarsson <> writes:
    >>>> bbxrider wrote:
    >>>>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});

    >
    > Still don't understand what it is that makes the above code "buggy".


    The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer, and
    there's no attempt made to detect or handle this event. Without going
    to the effort of reading the original post I don't know for sure, but
    I'd bet there's at least three or four other instances where CGI.pm
    handles things correctly that the OP's code does not.

    > What's important in those circumstances is that you validate the data
    > properly, run the program in taint mode, etc. Using CGI.pm does not
    > take care of everything, right?


    No, but it removes one axis of variability from the list of things
    that could be buggy. Given the option of using known-good code and
    hacking something up yourself, why (other than learning excercises,
    which are surely valuable) would you not use the tested and verified
    code?

    -=Eric
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, Nov 14, 2003
    #8
  9. Eric Schwartz wrote:
    > Gunnar Hjalmarsson <> writes:
    >>>>> bbxrider wrote:
    >>>>>
    >>>>>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});

    >>
    >> Still don't understand what it is that makes the above code
    >> "buggy".

    >
    > The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer,
    > and there's no attempt made to detect or handle this event.


    Some kind of exception handling is most often useful, but the lack of
    it isn't exactly a _bug_, is it?

    > Without going to the effort of reading the original post I don't
    > know for sure, but I'd bet there's at least three or four other
    > instances where CGI.pm handles things correctly that the OP's code
    > does not.


    None of us knows which of those "things" that are _applicable_ in OP's
    program.

    >> What's important in those circumstances is that you validate the
    >> data properly, run the program in taint mode, etc. Using CGI.pm
    >> does not take care of everything, right?

    >
    > No, but it removes one axis of variability from the list of things
    > that could be buggy. Given the option of using known-good code and
    > hacking something up yourself, why (other than learning
    > excercises, which are surely valuable) would you not use the tested
    > and verified code?


    I very much dislike the aggressive way in which some people here
    advocate the use of CGI, and the lack of faith that is shown in
    people's own judge. The described attitude makes me suspicious and
    less inclined to listen. How about that for a reason? :)

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Nov 14, 2003
    #9
  10. Gunnar Hjalmarsson <> writes:
    > Some kind of exception handling is most often useful, but the lack of
    > it isn't exactly a _bug_, is it?


    Is this buggy?

    open(FH, '>', "/root/file");
    print FH @data;

    I'd say heck yeah, because there's no checking that FH was properly
    opened, and that's the exact same class of bug we're talking about in
    the OP.

    >> Without going to the effort of reading the original post I don't
    >> know for sure, but I'd bet there's at least three or four other
    >> instances where CGI.pm handles things correctly that the OP's code
    >> does not.

    >
    > None of us knows which of those "things" that are _applicable_ in OP's
    > program.


    Does it matter? As long as there are any, it means that using CGI.pm
    (or some equivalent, such as CGI::Lite, or what-have-you) is a better
    solution than rolling it on your own. Again, I make exceptions for
    doing it for personal learning purposes, because it's good to learn
    how to do things, but it's just nuts to not use a module in a
    production environment.

    >> Given the option of using known-good code and
    >> hacking something up yourself, why (other than learning
    >> excercises, which are surely valuable) would you not use the tested
    >> and verified code?

    >
    > I very much dislike the aggressive way in which some people here
    > advocate the use of CGI, and the lack of faith that is shown in
    > people's own judge. The described attitude makes me suspicious and
    > less inclined to listen. How about that for a reason? :)


    I know you're being snarky, but I'll answer it honestly: it sucks as a
    reason. It's juvenile and immature, and overlooks the real benefits
    in favour of rebellion for its own sake. It's not that I have a lack
    of faith in people's judgement, it's that I have never-- not *once*--
    seen hand-rolled CGI parsing code on this newsgroup that wasn't buggy.

    Most of the arguments against using CGI.pm, including "it's too slow",
    aren't based on facts, they're based on suppositions, and "well, it
    stands to reason". Sometimes they're based on facts, and then people
    usually agree that that's a bad case to use it in, but I'd
    conservatively estimate that 98% of the time it's the way to go.

    I'll grant you, there are times when it's a good idea to roll your own
    CGI parsing routines. Personal study is one. I can't think of any
    situation for which I'd want to CGI.pm that it doesn't already work
    for, but if there is one, that's a good reason-- though a better idea,
    IMO, is to fix CGI.pm and thus make everyone's life that much better.
    Sometimes you don't need the HTML generation routines, and in that
    case there are modules like CGI::Lite and others that do the parsing
    job for you.

    In the end, there are a gazillion ways to get it wrong, and only a
    very few ways to do it right. And people being people, the sort of
    person who thinks they're saving time and effort by not using CGI.pm
    (or equivalent) is not as a rule the sort of person that's going to
    take the very painstaking approach of reading the RFCs and following
    them correctly, leading to the

    10 Hey, it works for me.
    20 <tweak>
    30 Oh, crap, now it's broke. <code>
    40 GOTO 10

    loop we're all so painfully familiar with.

    -=Eric
    --
    Come to think of it, there are already a million monkeys on a million
    typewriters, and Usenet is NOTHING like Shakespeare.
    -- Blair Houghton.
     
    Eric Schwartz, Nov 14, 2003
    #10
  11. Gunnar Hjalmarsson <> wrote in news:bp1c15$1in3ke$1@ID-
    184292.news.uni-berlin.de:

    > Eric Schwartz wrote:
    >> Gunnar Hjalmarsson <> writes:
    >>>>>> bbxrider wrote:
    >>>>>>
    >>>>>>> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    >>>
    >>> Still don't understand what it is that makes the above code
    >>> "buggy".

    >>
    >> The read() may not read $ENV{'CONTENT_LENGTH'} bytes into $buffer,
    >> and there's no attempt made to detect or handle this event.

    >
    > Some kind of exception handling is most often useful, but the lack of
    > it isn't exactly a _bug_, is it?


    OK, you can call it something else then. Let's assume you don't care about
    that. There is still the fact that

    >>>>>>> @pairs = split(/&/, $buffer);


    will miss pairs separated by a semicolon. In addition, parameter names are
    not unescaped. What happens when the query string given is

    ?param=;

    > I very much dislike the aggressive way in which some people here
    > advocate the use of CGI, and the lack of faith that is shown in
    > people's own judge.


    As Eric Roode pointed out, the same exact code has been posted here
    numerous times (e.g. http://groups.google.com/groups?hl=en&lr=&ie=UTF-8
    &oe=UTF-8&safe=off&selm=4096148f.0310161157.9400327%40posting.google.com)
    so I assumed the OP was not relying on his own judgement, but using someone
    else's code. In that case, he is better off using CGI.pm.

    Sinan.
    --
    A. Sinan Unur

    Remove dashes for address
    Spam bait: mailto:
     
    A. Sinan Unur, Nov 14, 2003
    #11
  12. "Eric J. Roode" <> wrote in
    news:Xns9432C1A592BAFsdn.comcast@216.196.97.136:

    > "bbxrider" <> wrote in
    > news:7cUsb.139690$mZ5.963708@attbi_s54:

    ....
    >> read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    >> @pairs = split(/&/, $buffer);
    >> foreach $pair (@pairs) {
    >> ($name, $value) = split(/=/, $pair);
    >> $value =~ tr/+/ /;
    >> $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    >> $FORM{$name} = $value;

    ....
    > We keep seeing this exact same bad code posted to this newsgroup. Out
    > of curiosity, where did you copy it from?


    It seems to date back to 1996 or even earlier:

    http://tinyurl.com/uxq2

    --
    A. Sinan Unur

    Remove dashes for address
    Spam bait: mailto:
     
    A. Sinan Unur, Nov 14, 2003
    #12
  13. bbxrider

    bbxrider Guest

    thanks for all the help and opinions
    i'm just self learning perl and found some code at
    http://www.cgi101.com/class/
    and some other searching google groups
    actually i dont even know what cgi.pm and cgi lite are but will surely find
    out
    i dont' mean to try and just steal code, but have found that seeing, using
    and understanding examples
    really accelerates my learing curve
    what i've since found is that the variable containing the form input is in
    fact in the same order as the form
    this code keeps the original order
    foreach (split(/[&;]/, $buffer)) {
    s/\+/ /g ;
    ($name, $value)= split('=', $_, 2) ;
    $name=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
    $value=~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/ge ;
    print "$name = $value";
    $buffer{$name}.= "\0" if defined($in{$name}) ; # concatenate
    multiple vars
    $buffer{$name}.= $value ;
    }
    i have already set up sql query based inserts that expect the data fields in
    order and since there are 67
    on the form i want to be able to reuse that code
    again thanks for the help, this is a great forum and would hope to return
    the help someday

    "Eric J. Roode" <> wrote in message
    news:Xns9432C1A592BAFsdn.comcast@216.196.97.136...
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > "bbxrider" <> wrote in
    > news:7cUsb.139690$mZ5.963708@attbi_s54:
    >
    > > is there a way to sort (or other method) the 'method=post' data
    > > fields from a form into
    > > the same order they appear in the form
    > > when i use the following code there doesn't appear to be any
    > > particular order to how they are arranged

    >
    > The CGI spec does not guarantee that the form variables will be submitted
    > in any particular order, so you're out of luck.
    >
    > > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
    > > @pairs = split(/&/, $buffer);
    > > foreach $pair (@pairs) {
    > > ($name, $value) = split(/=/, $pair);
    > > $value =~ tr/+/ /;
    > > $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
    > > $FORM{$name} = $value;

    >
    > This is exceedingly bad code. Unless you really know what you're doing,
    > and have strong reasons not to, you should use the CGI module.
    >
    > We keep seeing this exact same bad code posted to this newsgroup. Out of
    > curiosity, where did you copy it from?
    >
    > - --
    > Eric
    > $_ = reverse sort $ /. r , qw p ekca lre uJ reh
    > ts p , map $ _. $ " , qw e p h tona e and print
    >
    > -----BEGIN PGP SIGNATURE-----
    > Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
    >
    > iQA/AwUBP7Qbf2PeouIeTNHoEQKb6gCfbgrhGAcLpyRLTC5cUW4U1AsVIsQAn3Ev
    > bAiVGyJb/3J4v/fhU4Yi9w1q
    > =vDoO
    > -----END PGP SIGNATURE-----
     
    bbxrider, Nov 14, 2003
    #13
  14. A. Sinan Unur wrote:
    > There is still the fact that
    >
    >>>>>>>>@pairs = split(/&/, $buffer);

    >
    > will miss pairs separated by a semicolon.


    Not applicable. Look at OP's original post again. Parameters submitted
    via forms using the POST method are not separated by semicolons.

    > In addition, parameter names are
    > not unescaped. What happens when the query string given is
    >
    > ?param=;


    Nothing, since the code does not parse query strings.

    I know that you know better than that, Sinan. But now we are talking
    about the 'sacred cow' CGI.pm, so the usually educated, logical posts
    from you are suddenly replaced with incorrect or questionable
    statements. It's anything but convincing.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Nov 14, 2003
    #14
  15. Eric Schwartz wrote:
    > Gunnar Hjalmarsson writes:
    >> I very much dislike the aggressive way in which some people here
    >> advocate the use of CGI, and the lack of faith that is shown in
    >> people's own judge. The described attitude makes me suspicious
    >> and less inclined to listen. How about that for a reason? :)

    >
    > I know you're being snarky, but I'll answer it honestly: it sucks
    > as a reason. It's juvenile and immature, and overlooks the real
    > benefits in favour of rebellion for its own sake.


    Maybe true, when you look at it from a rational angle. But it's human.

    See my latest reply to Sinan. (This is my last post in this thread, I
    promise. :) )

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Nov 14, 2003
    #15
  16. bbxrider

    Ben Morrow Guest

    [please don't top-post]

    "bbxrider" <> wrote:
    > thanks for all the help and opinions i'm just self learning perl and
    > found some code at http://www.cgi101.com/class/ and some other
    > searching google groups actually i dont even know what cgi.pm and
    > cgi lite are but will surely find out


    For CGI, type 'perldoc CGI' at a command prompt. CGI::Lite you would
    need to install. Note that the names of Perl modules are case-sensitive.

    > i dont' mean to try and just steal code, but have found that seeing,
    > using and understanding examples really accelerates my learing curve


    Absolutely. Reading decent code is one of the best ways to learn. You
    do have to be sure your source is reliable, though: there is one hell
    of a lot of very bad Perl floating around the web.

    > what i've since found is that the variable containing the form input
    > is in fact in the same order as the form this code keeps the
    > original order


    I don't think this is guaranteed, by which I mean that it may happen
    to work for you with your browser during this phase of the moon, but
    under other circumstances it may well not. If you need to keep
    separate track of the different paramaters, give them different
    names. Change whatever generates them to put a number on the end, or
    something.

    Ben

    --
    For the last month, a large number of PSNs in the Arpa[Inter-]net have been
    reporting symptoms of congestion ... These reports have been accompanied by an
    increasing number of user complaints ... As of June,... the Arpanet contained
    47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] *
     
    Ben Morrow, Nov 14, 2003
    #16
  17. Gunnar Hjalmarsson <> wrote in news:bp1hn3$1is5k8$1@ID-
    184292.news.uni-berlin.de:

    > A. Sinan Unur wrote:
    >
    >> In addition, parameter names are not unescaped.
    >> What happens when the query string given is
    >>
    >> ?param=;

    >
    > Nothing, since the code does not parse query strings.


    Hmmmm ... Let's say I have been doing too much 'task-switching' today,
    leading to muddled thinking.

    > But now we are talking about the 'sacred cow' CGI.pm, so the
    > usually educated, logical posts from you are suddenly replaced with
    > incorrect or questionable statements.


    It is not that ... Simply jumbled neural paths or something. I do
    apologize.

    Sinan.

    --
    A. Sinan Unur

    Remove dashes for address
    Spam bait: mailto:
     
    A. Sinan Unur, Nov 14, 2003
    #17
  18. bbxrider

    Keith Keller Guest

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2003-11-14, Gunnar Hjalmarsson <> wrote:
    >
    > Not applicable. Look at OP's original post again. Parameters submitted
    > via forms using the POST method are not separated by semicolons.


    What if he wants to support GET in the future?

    > Nothing, since the code does not parse query strings.


    What if he wants to parse query strings in the future?

    - --keith

    - --
    -francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

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

    iD8DBQE/tFDihVcNCxZ5ID8RApBfAJ90LhcK0PGkyyZv/7q5Mhfag4/rogCeLNcn
    MIWcADFGVC1a1mzcW+V1Nvc=
    =GtN2
    -----END PGP SIGNATURE-----
     
    Keith Keller, Nov 14, 2003
    #18
  19. bbxrider

    bbxrider Guest

    what is 'top-post' ???
    actually don't understand how the eric roode and first sinan unur posts were
    not subordinated to the post immediately above them,
    i simply use reply-to-group and it always subordinates to the post i'm
    responding to

    "Ben Morrow" <> wrote in message
    news:bp1hue$mj7$...
    > [please don't top-post]
    >
    > "bbxrider" <> wrote:
    > > thanks for all the help and opinions i'm just self learning perl and
    > > found some code at http://www.cgi101.com/class/ and some other
    > > searching google groups actually i dont even know what cgi.pm and
    > > cgi lite are but will surely find out

    >
    > For CGI, type 'perldoc CGI' at a command prompt. CGI::Lite you would
    > need to install. Note that the names of Perl modules are case-sensitive.
    >
    > > i dont' mean to try and just steal code, but have found that seeing,
    > > using and understanding examples really accelerates my learing curve

    >
    > Absolutely. Reading decent code is one of the best ways to learn. You
    > do have to be sure your source is reliable, though: there is one hell
    > of a lot of very bad Perl floating around the web.
    >
    > > what i've since found is that the variable containing the form input
    > > is in fact in the same order as the form this code keeps the
    > > original order

    >
    > I don't think this is guaranteed, by which I mean that it may happen
    > to work for you with your browser during this phase of the moon, but
    > under other circumstances it may well not. If you need to keep
    > separate track of the different paramaters, give them different
    > names. Change whatever generates them to put a number on the end, or
    > something.
    >
    > Ben
    >
    > --
    > For the last month, a large number of PSNs in the Arpa[Inter-]net have

    been
    > reporting symptoms of congestion ... These reports have been accompanied

    by an
    > increasing number of user complaints ... As of June,... the Arpanet

    contained
    > 47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] *

     
    bbxrider, Nov 14, 2003
    #19
  20. In article <bp1c15$1in3ke$-berlin.de>, Gunnar
    Hjalmarsson wrote:

    > Eric Schwartz wrote:


    [re: CGI.pm]

    >> No, but it removes one axis of variability from the list of things
    >> that could be buggy. Given the option of using known-good code and
    >> hacking something up yourself, why (other than learning
    >> excercises, which are surely valuable) would you not use the tested
    >> and verified code?

    >
    > I very much dislike the aggressive way in which some people here
    > advocate the use of CGI, and the lack of faith that is shown in
    > people's own judge. The described attitude makes me suspicious and
    > less inclined to listen. How about that for a reason? :)


    Looking at the question and the answer, in isolation at least, I'm going
    to assume the use of "reason" there is irony. :)

    dha

    --
    David H. Adler - <> - http://www.panix.com/~dha/
    'Don't be tempted to veer off!'
    - Paul McGann
     
    David H. Adler, Nov 14, 2003
    #20
    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. Jack
    Replies:
    2
    Views:
    555
  2. Luca Fini

    help on how to arrange python code

    Luca Fini, Oct 18, 2003, in forum: Python
    Replies:
    0
    Views:
    437
    Luca Fini
    Oct 18, 2003
  3. PraVeeN

    Gridview columns re-arrange

    PraVeeN, Dec 8, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    398
    PraVeeN
    Dec 8, 2006
  4. Kent
    Replies:
    6
    Views:
    377
    Terry Reedy
    Mar 28, 2009
  5. Peter K

    arrange order of displayed strings?

    Peter K, Apr 27, 2010, in forum: ASP .Net Web Controls
    Replies:
    0
    Views:
    728
    Peter K
    Apr 27, 2010
Loading...

Share This Page