http://www.perlmonks.org?node_id=70972


in reply to Re: "Action" variables and form data
in thread "Action" variables and form data

Yet another example of why not to roll your own.

First of all you assumed that the query string only has one name/value pair. What if it has more? Use a hash? Well what if there are multiple name/value pairs? What if someone for testing turns a post back into a get to collect a URL and then wonders why their code broke?

Plus did you consider the poor schmuck who will use your code with form data that has been modified in escaping? At least you warned people that you got the first wrong. But you should also be pointing people to URI::Escape so they can decode the data.

No, it is far better to do as CGI intentionally does and leave get/post transparent within the CGI so that the developer can easily switch, and just use hidden form elements as they were intended rather than trying to mix and match.

  • Comment on Re (tilly) 2: "Action" variables and form data

Replies are listed 'Best First'.
Re: Re (tilly) 2: "Action" variables and form data
by kha0z (Scribe) on Apr 10, 2001 at 00:39 UTC
    That is a very good point. And one that, as a newbie, I forgot to point out. However, I may be wrong, but it think that it is always important to remember that in perl "there is more than one way to do it". That said maybe it is not the best but it is a possible solution to an imidiate problem. Anyway, we should alays comment on these fixes so that we can review them later and that others can improve on our code as well.

    Thanks for bringing up that point. :)

    Update:I stand corrected. Throught the examples and arguements that have been presented, I think that I understand, that by trying to parse through the quesry string myself all I am doing is tring to rewrite a function that is already in CGI.pm. This didn't make sense to me at first, until I sat and thought about it. I agree that instead of writing a quick fix to the problem. We should be robust enough to look at the module and understand how it works and use it to its full potential instead of trying to rewrite the API ourselves.

    kha0z -- www.kha0z.net

      kha0z wrote:
      I may be wrong, but it think that it is always important to remember that in perl "there is more than one way to do it".

      There is definitely more than one way to do it, but mixing GET and POST is still wrong -- though I realize you're not advocating that here. GET and POST are not the same and shouldn't be used as such. In this post, I wrote:

      As a general rule of thumb, use GET when you get information from a server without changing it. Use POST when you post information to a server and thus change it. That's why we have two methods.

      That's the rule of thumb to remember, but there are technical distinctions as well. See the aforementioned link for a bit more information. Blindly mixing the two usually doesn't cause problems, but like so many issues of its kind, the intermittant problems that can result are very difficult to diagnose.

      Cheers,
      Ovid

      Update: Ugh. I just read kha0z's original post. Amongst other things, /s?he/ advised "Parse the query string yourself yourself." This is bad. Very bad. First, not only does CGI.pm parse the query string for you, thus causing your parsing of the query string to be rewriting code, but the "roll your own" parsing that kha0z suggested is terribly broken.

      Obviously, I can't be that good of a programmer if I failed to note the "context" of the node I was replying to :)

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        For one, you can only get resumable downloads with GET and not POST