$_POST inside class functions?

[waynew]

I usually do something like so:

 

$class = new Class();
$res = $class->function($_POST['variable']);

 

Is it better to do that, than say:

 

<?php
class Class{
     function function(){
         $variable = $_POST['variable'];
     }
}
?>

 

Which is considered better practise or is it a matter of preference?

[jxrd]

What's the point in passing a superglobal to a function?

 

[waynew]

That's what I was thinking. I just thought it made my classes a bit cleaner.

[dbo]

I suppose it would depend on the application. If you are 100% sure that you will only use $_POST in the class then you can probably get away with it. If there is ever a chance you might want to use $_GET, $_SESSION or perhaps some other user defined variable then you've just painted yourself into a corner.

 

Personally I don't ever directly reference $_POST directly like that. I always take that data and run it through a validation/cleansing/escaping routine and store it in a $clean array. You know that any data in the $clean array is clean so I would be passing $clean['variable'] into my class rather than $_POST['variable'].

 

Multiple ways to do this, just giving you some food for thought....

[Daniel0]

What's the point in passing a superglobal to a function?

 

Portability.

 

Personally I don't ever directly reference $_POST directly like that. I always take that data and run it through a validation/cleansing/escaping routine and store it in a $clean array. You know that any data in the $clean array is clean so I would be passing $clean['variable'] into my class rather than $_POST['variable'].

 

I would regard that as sort of bad practice. The "cleanliness" of a value depends on the context in which it is used.

[dbo]

I would regard that as sort of bad practice. The "cleanliness" of a value depends on the context in which it is used.

 

It's not a generic function that does this, it would only be used in context to which rules applied to the current situation. In my class I assign a series of rules depending on the problem at hand and it validates according to those rules. If it passes it is available in the clean array, if it fails one or more errors are available and can be referenced by key.

 

So unless I'm missing what you're saying. I agree that it depends on the context, thus it validates/stores based on context rather than being a generic catch all routine.

[Daniel0]

Ah, okay I see. I just sometimes see some people do something like this:

$_GET = array_map('mysql_real_escape_string', $_GET);

 

I thought that was what you meant.

[dbo]

Grossness, negatory.

 

If you've ever done any ASP.NET development it's mainly similar to the validation controls you can use. It's pretty cool because I can write code without worrying about all the input validation crap and then after the fact I can easily drop it in. It's probably not the best way to do it still, but it's come in pretty handy. You do like:

 

RuleValidator::register('email', 'Email');
RuleValidator::addIsNotNull('email', '{name} is required.');
RuleValidator::addIsEmail('email', 'Invalid format for {name}.');

 

I typically extend this class and can call it by like:

 

if( RuleValidator::isValid('Contact') )
{
   //send the email
}

 

You can pluck the 'clean' variables out of the array using

 

$email = get_clean('email');

 

Then if it needs escaped as part of the query that's when I'll run it through mysql_real_escape_string().

 

Like I said I'm sure there is a better way to do this, but it's what I came up with some time ago and I've not had a need to rework it yet, but if you have any suggestions I'd be happy to listen

[Daniel0]

Looks sort of like the facilities that Zend_Form gives you coupled with Zend_Validate and Zend_Filter.

[waynew]

Daniel, could you explain what you meant when you said portability?

 

I suppose it would depend on the application. If you are 100% sure that you will only use $_POST in the class then you can probably get away with it. If there is ever a chance you might want to use $_GET, $_SESSION or perhaps some other user defined variable then you've just painted yourself into a corner.

 

Personally I don't ever directly reference $_POST directly like that. I always take that data and run it through a validation/cleansing/escaping routine and store it in a $clean array. You know that any data in the $clean array is clean so I would be passing $clean['variable'] into my class rather than $_POST['variable'].

 

Multiple ways to do this, just giving you some food for thought....

 

I usually handle my validation etc inside the class. I have an error object (which is admittedly, just a glorified array) that I pass to the rest of my objects to keep track of errors.

 

function myfunction($variable){
   if($variable != "etc"){
       $this->error->add("Error message");
   }
   
   //later on
   if($this->error->errors_exist()){
        return false;
   }
}

[Daniel0]

Essentially you should strive for as loose a coupling between entities as possible. If you read a global from within a function you will have created a coupling between that global object (not talking about OOP objects here necessarily) and your function. This means you can only ever use that function with, in your case, $_POST. If you on the other hand pass the value by argument you won't make a coupling (= dependency), but will work with any type of scalar value (edit: array of scalar values obviously as that is what $_POST is). You should limit your usage of the super globals, and you should never create additional globals yourself.

[waynew]

Thanks! And understood.