$_post

Hi,
Which way do you prefer, redefined $abc= $_POST['abc']; and use $abc all over script or just use $_POST['abc'] all over the script?

Thanks,
John

hmm good question,...never really thought about it before,...
I can say that for now,...I am using $_POST['var'] within my scripts.

I am curious if it there is less strain on the interpreter to do

$_POST['looooooong_var_name'] = $var;

in other words,...replacing a long variable with a shorter one.

$var = $_POST all the way, only because it makes code look more cleaner and easier to look at. Rater than having $_POST[] all over the place, i grab all the $_POST varibles at the top of the script.

also,
$_POST['var2'] = $var3; - wouldnt work, but



will work.

Disagree with the last post 100%.

Why redefine something you already have defined just so it looks "PRETTIER"?

There's a reason why REGISTER GLOBALS is turned off be default in the later versions of PHP. Why defeat the purpose by doing this?

Actually none of you are 100% right.

First on the point of 'prettiness', many people would define this as 'neatness' and, furthermore, 'readability'. I find it easier to manage my variables when they're in container arrays, such as $_POST, $_GET, it doesn't really matter in the long run. Obviously, using $_POST['var'] takes more typing than just $someVar, but it's easier to identify and recognize.

That brings me to my second point. Something none of you touched on was the fact that you HAVE to verify all your REQUEST data in order to keep your application safe and running smoothly. If you're letting someone upload a file, check the size (NOT by relying on HTML). If they're putting in text, addslashes if you need to, check for html if it's not allowed, etc. You have to look at REQUEST data as unreliable and unsafe.

Finally, a basic example...


This is obviously pretty basic, the user is submitting the form clicking on a button named submit. The form method is post. The user is submitting the field strUserText. We remove any html special characters from the text, and add slashes to escape out any data that may cause php (or our database) any trouble.

Once that's done, $strUserText is ready to go into your db, or file, or whatever. I could've just as easily done $_POST['strUserText'], but it's just simpler to type strUserText. Additionally, preserving the original user submitted values can come in handy for later processing.

In the end, it's a matter of preference. What's most important is that you are CONSISTENT.

ok, just my 2c

firstly while it maybe slightly easier to use a variable like $value instead of $_POST['value']

there are several advantages to using $_POST, etc

firstly when you have

$value = $_POST['value']

the server then has to store another variable with the same data. This is just a waste of resources. This wastes time and resouces of the server.

Its easier to find a variable with $_POST then $variable.

having said that.

I do sometimes define one of my _POST arrays as a normal variable, if im using that variable in alot of strings.

eg

"this is a $test" x50

instead of

"this is a {$_POST['test']}"

using $test over {$_POST['test']} in a string does have a slight speed advantage.

So if i have to use a post var in more then 3 strings i usally convert it to a normal var

Ben,.....what if you do in fact have $_POST['var'] x 50,..lol,...is it more of a server strain to reference it by the $_POST array then by a renamed $var?

There is only more strain on the server if the $_POST is located in a string

if you using it like

echo $_POST['var'];

or

$sum = $_POST['var'] * 50;

then there is no point in defining a new variable for it.

If you want to simplify your code by eliminating $_POST just use a reference to the post value you want. If you're going to do a lot of processing on it, it's probably just easier to put it another var. but if you just want to not have to type post, and not have memory problems, just do
$var =& $_POST['var'];
that doesn't really waste resources, since a reference only contains a memory location ;P

Doing references or something like that is fine for SMALL projects of 1 or MAYBE 2 people.

If you did something like that in a large project I would personally seek you out and make your life miserable. You're introducing greater and greater possibilities for variable collision like this.

Have you ever had post/cookie/file variables colliding? THAT'S WHY YOU LEAVE THE VARIABLES IN THEIR RESPECTIVE CONTAINERS. You're eliminating the possibility of variable collision. And by creating these extra variables you're introducing the possibility of variable poisoning AGAIN.

You shouldn't have variables colliding anyway, not request data... but I won't get into an argument about good coding practices.

As I've said, and can be quoted on over and over, USE THE SUPERGLOBALS. I simply gave a legitimate alternative if someone doesn't want to type out $_POST 75,000 times to process a website registration form or something =( I don't think most people on this forum are making large scale ecommerce sites, so, while I appreciate your input, the hostile tone was a bit unneccessary.

/me changes name to =(

/me no like hostility :/

It was meant in a sarcastic manner but yeah that doesn't carry to well on the net. sorry about that.

It doesnt matter which method you use, as long as it parses the correct html code to the user.

In my opinion the superglobals should always contain their original value. If you need to change the data, make a new working variable. I feel the same way with functions/methods.

This way, if you have to access the original data somewhere else in the code, you won't have to do any changes to the code in order to get that data. Let's take a look at an example:



oops, we're assigning the variable with slashes added to _userName.. I agree, this is a bad example, but bear with me. Instead of doing it like that, you can assign $name to a new variable in the beginning of the method.. You could make your own prefixes for variables.. Let's say, i for input and w for working.



As I said before, this is a rather bad example, but hopefully you'll see what I mean..

So instead of using and changing the data in the superglobals all over the script, at least I recommend making a local copy that you can work with, and change the value of as much as you'd like, while still being able to access the original data through the superglobal.

Well, this is at least how I feel about the issue...

I agree with the guy that said just use $_POST['var']

I have so many variables in some projects, if I start "renaming" them, I am kickin' myself in the arse later.

I inherited a bunch of code wherein the programmer wasn't using superglobals at all to start with (for $_GET["var"] or $_POST["var"] or $_SESSION["var"], he was always just using $var). On top of that, he was creating all sorts of other variable names, many of which were nondescriptive and hard on the eyes. Reading the code and figuring out where things are coming from has proven to be a real nightmare. I'm a strong advocate of using the superglobals.

As for saving old user input, why save it if you don't need it? If you find out you need to keep an old piece of input, duplicate the one piece and save that much in the way of resources. Or if you must keep it all for some reason (again, since this is run-time and not stored data, why bother if you're not going to use it?), I'd consider copying the superglobal into an array for safe keeping and still using the superglobal throughout the script to keep scope transparent.