[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