Pages

Tuesday, September 27, 2011

When does assigning variables become more efficient than $_POST?

**NOTE: I wrote this a really long time ago (February 1, 2009) on another blog I used to have and wanted to move some of the articles over here to consolidate them.
To answer the question presented by the article title... All the time!

I was tooling around today and ran across this little gem...

This may not be a big deal, but I'm just kinda curious. If I have a page that submits a form to itself, when is it better to assign each element in $_POST to a variable to use for the rest of the page?

My situation probably doesn't make a difference, but say I have about 10 form fields, and when the page is posted back to itself, i call each of those form fields 2 times (1 for error checking, 1 for SQL insert, or to pre-fill form).

So where does it become more efficient to only call $_POST once and assign those to variables? Do you use the variables if they are needed any more than one time?

Thanks for you thoughts!

IMHO that is a great question!

I believe that the question is best addressed in two parts.
  1. Variable \Reuse
    • This is the one I would like to focus upon today.
  2. Benchmarking

Variable Reuse

Anytime that you plan on using data from the $POST variable (or any request data $_REQUEST, $_GET, et al) in more than one place, it is good practice to contain that data in a variable.

Why?

Let's say you have a name passed into your script via a form that a user submitted. Our POST data could look something like this:

$_POST['firstname'] == 'John'$_POST['lastname'] == 'Smith'

So anytime we want to do something with the first name we simply use the variable

$_POST['firstname']

// Will output John
echo 'First Name: ' . $_POST['firstname'];

That's nice and easy... but if you do plan to use that technique remember, there's a catch!

What if you wanted to use that firstname value for not only outputting to the browser but for other things like inserting into a database and/or retrieving data from a database, etc? Well you could use $_POST['firstname'] over and over again EXCEPT remember that the $_POST variable is a special predefined variable. In reality all the request variables are arrays. Thus when you use 'firstname' you are actually referring to the associative key ('firstname') contained within the array ($_POST) and returning its value ('John'). Well that's all fine and good except what if the key changes to something like, oh let's say 'user_firstname'? This now means that someone (probably you) is going to be tasked with renaming each and every one of the times it was called throughout the script. What about find/replace? That could work but what if it misses just one entry (happened to me today: it was my fault it happened but the fact is, it still happened)? Now you have problems. You now are gifted with a bug that if your lucky you can track down easily and if your not... let's just say that baldness amongst programmers isn't usually caused by inheritance.

Anyway, this potential dilemma is easily solved by containing that data in one central location... a variable.
$firstname = $_POST['firstname'];
$lastname = $_POST['lastname'];

Now since your data is contained within its own variable, if the key changes you only have to edit one time and it will be seen throughout the rest of the script!

Example:
// This example shows the benefit of using variables to contain request
// data request values
// $_POST['firstname'] == 'John'
// $_POST['lastname'] == 'Smith'

// Since we are containing the data here then this ends up being the
// only place that the post key has to be changed.
$firstname = $_POST['firstname'];
$lastname = $_POST['lastname'];

function showFullName() {
    echo $firstname . ' ' . $lastname;
}

function insertRecord() {
    $query = "INSERT INTO mydb.ppl VALUES ($firstname, $lastname);
}

Working On Another Site

YAY!!!

I have been working on another site recently for a small business located in Tampa Florida called Avalon Transcription and Document Preperation, LLC.

Take a look at it and let me know what you think :)
Avalon Transcription and Document Preparation, LLC


New Version
Old Version

Thursday, September 22, 2011

Two New Sections (Pages)

I have created two new pages to address user issues with SMS Text Auto Responder. Why does this feel like I need to start thinking about site expansion and evolution... ugh whatever...

Image: Danilo Rizzuti / FreeDigitalPhotos.net
Anyway, I have created a FAQ page where I will answer the most asked questions by users. There is also a page called "My Response to Android Marketplace Comments" On this page I will be directly answering user comments from the Android Marketplace.

The FAQ page is just starting so there is very little content just yet.

The "My Response to Android Marketplace Comments" page has comments and my responses starting from September 1, 2011

Enjoy :)

Saturday, September 17, 2011

Just For Fun...

Just for fun, I thought I would show everyone a preview of the redesign for SMS Text Auto Responder v2...

Let me know what you think so far :)




Monday, September 12, 2011

Newest Update w/ Screen Shots

Version 1.2:
  • Major update to the UI (User Interface)
  • Bug fix in the home screen widget
  • Added AdMob ads...
    • Hopefully these ads will help to offset some of the financial costs that go into maintaining and creating new features for SMS Text Auto Responder.