[FX.php List] $_REQUEST

Leo R. Lundgren leo at finalresort.org
Wed Jul 30 16:30:07 MDT 2008


I usually do this when fetching incoming data:

	// First, fetch the variable if it's set, otherwise set a default  
value (so that the rest of the code can concentrate on doing what its  
function is, instead of checking if the variable is set at all and so  
on).
	$messageId = (isset($_REQUEST['smsid']) ? $_REQUEST['smsid'] : '');
	$statusCode = (isset($_REQUEST['status']) ? $_REQUEST['status'] : '');
	$timestamp = (isset($_REQUEST['timestamp']) ? $_REQUEST 
['timestamp'] : '');

	// Then, if/when appliable, do input validation.
	if(!strlen($messageId)) {
		throw new Exception('Missing messageId.');
	}
	if(!strlen($statusCode)) {
		throw new Exception('Missing statusCode.');
	}
	if(!strlen($timestamp)) {
		throw new Exception('Missing timestamp.');
	}

This was just a simple example; Your real input validation would  
often check formatting of some data (using preg_match() for example),  
or it could make sure that $someInput exists $someWhereElse (a  
database, perhaps?), etc. In any case, I think it's a nice  
separation; First you grab the data, then you validate it (as far as  
possible), and then the rest of your code can be cleaner.

I'm often using the empty string '' as default value since I find  
checking emptyness using strlen() to be very conventient (just  
comparing to true won't help you if the variable contains "0" since  
that evaluates to false, that's one little caveat). I've actually  
tested the strlen() performance, and it's nothing to worry about.

You may notice that I'm using $_REQUEST here. I usually don't, I use  
GET and POST for what they're made for. But in this case I need to  
support both methods because of some really dumb client  
implementations, so there's no use in doing the above in any other  
way. I also know what I can expect with the incoming requests, so  
take my word for it :P But don't take this as a vote for "use  
$_REQUEST". I would recommend against it in your previous post. The  
day that you don't have to ask yourself that question, is the day  
when you can use $_REQUEST ;-)

Anyhow, I think i came a bit off topic here. I think it's just a  
matter of taste which one of your examples that you go with..  
Personally, it depends on the size of the good and bad blocks, and  
which one feels most logican to have as the "exception" in the  
current context. It varies for me at least. But in your example it  
feels more like you're testing whether to go on with your code, than  
testing for errors. I guess one can say that you are expecting  
success more than failure, and in that case I vote for having the  
good block first and the exception/failure last. I'd probably do  
something like the first one.

// Late night ramblings.


31 jul 2008 kl. 00.00 skrev Jonathan Schwartz:

> I assumed that everyone has this challenge. Folks arrive to a given  
> page from either a link using a GET or a from using a POST. Let's  
> say that we need to edit the page and the recid is the field in  
> question. Either the GET or the POST has to contain a recid or it's  
> a no go....
>
> if(isset($_GET['recid']) or isset($_POST[recid])
> {
> Good
> }else{
> Bad
> }
>
> or, the other way...
>
> if(!isset($_GET['recid']) and !isset($_POST[recid])
> {
> Bad
> }else{
> Good
> }
>
> Of course, just testing for empty isn't good enough, so this code  
> starts to expand. ;-)
>
> Just thought that the $_REQUEST was a simpler approach that I had  
> overlooked.
>
> J
>
>
> At 4:40 PM -0500 7/30/08, Andrew Denman wrote:
>>
>> I have not yet had an instance where I'm using both POST and GET so I
>> haven't used $_REQUEST and cannot provide first-hand experience.
>> detection.
>>
>> Andrew Denman
>
> -- 
> Jonathan Schwartz
> Exit 445 Group
> jonathan at exit445.com
> http://www.exit445.com
> 415-370-5011
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list


-|



More information about the FX.php_List mailing list