Menu
Community /Pin to ProfileBookmark
@NogDogSep 19.2006 — #The "get" method (URL query string) is normally preferred when sending data that is only to be used for "read only" type operations. A typical example of this is search queries. Note that Google transmits your search queries via a URL query string; and I suspect the folks at Google have at least a little idea about what they are doing. One obvious advantage is that you can bookmark a query result, but if it it were transmitted via the post method you could not.
The post method should be used for data which will potentially change something, for instance an e-business order form or a forum registration form. (Think of things where you would [i]not[/i] want the user to be able to bookmark the results page and thereby submit a new request each time they accessed that bookmark.)@NogDogSep 20.2006 — #Not exactly, register_globals instantiates global variables whose names are the same as the form or query string variable name. Regardless of the register_globals setting, those same values are stored in the $_GET array (if it's from a query string) or the $_POST array (from "post" method forms).
The current "best practice" is to leave register_globals off and always access your variable via the applicable array. So if the link to your page is "somepage.php?var1=1&var2=2", then you would access the two variables as $_GET['var1'] and $_GET['var2']. Since such access will work regardless of whether or not register_globals is enabled, always doing so makes your scripts more portable since they are independent of that configuration setting. Also, having register_globals on leaves an opening for accidental or malicious overwriting of script variables via the URL, thus the evolution to having register_globals turned off as the default setting.
Passing Variables w/o address string
Hey guys,
One of my clients uses a host that doesn’t allow variable passing/modification via a URL (ie: snap.php?wut=yes). The solution I’ve been using to pass data from page to page has been $_POST variables and making forms out of everything, but this isn’t as flexible as I’d like. Also, people get the “This Page has been loaded from POST Data” pop up if they try to navigate away… which is lame.
The latest request the client has given is a drop-down menu that loads a pop-up window of dynamic content. I have no idea how to do that via forum submission.
Any ideas? In general, do you have any tips for better variable handling?
If you have any suggestions, such as learning sessions (which comes to mind), can you please provide a link to some resource that you’ve found helpful?
Thanks!
Sign in
to post a comment8 Comments(s) ↴
0
@NogDogSep 19.2006 — #The "get" method (URL query string) is normally preferred when sending data that is only to be used for "read only" type operations. A typical example of this is search queries. Note that Google transmits your search queries via a URL query string; and I suspect the folks at Google have at least a little idea about what they are doing. One obvious advantage is that you can bookmark a query result, but if it it were transmitted via the post method you could not.The post method should be used for data which will potentially change something, for instance an e-business order form or a forum registration form. (Think of things where you would [i]not[/i] want the user to be able to bookmark the results page and thereby submit a new request each time they accessed that bookmark.)
0
@NogDogSep 20.2006 — #Not exactly, register_globals instantiates global variables whose names are the same as the form or query string variable name. Regardless of the register_globals setting, those same values are stored in the $_GET array (if it's from a query string) or the $_POST array (from "post" method forms).The current "best practice" is to leave register_globals off and always access your variable via the applicable array. So if the link to your page is "somepage.php?var1=1&var2=2", then you would access the two variables as $_GET['var1'] and $_GET['var2']. Since such access will work regardless of whether or not register_globals is enabled, always doing so makes your scripts more portable since they are independent of that configuration setting. Also, having register_globals on leaves an opening for accidental or malicious overwriting of script variables via the URL, thus the evolution to having register_globals turned off as the default setting.