The documentation for the Validation Class shows "trim" being used as a validation rule.
However, I've found that adding the rule:
$val->add_field('username', 'Username', 'trim')
Does not actually "trim" the values:
Input::post('username') or $_POST
It seems, from the documentation, that this should work since the documentation shows:
"The first parameter of the add_rule() method can contain PHP native function names"
I can extend the Validation Class to implement the desired result but that requires writing the rule as:
$val->add_field('username', 'Username', 'trim[username]')
The field's VALUE is automatically passed to the validation rule as a parameter.
Shouldn't the field NAME also be automatically passed?
Also, is there a way to update a $_POST value using the Input Class?
The reason?
I would like the code to be consistent and avoid issues later such as figuring out that the Session Class doesn't actually use $_SESSION.
BTW, the docs for the Session Class should point this out.
$_POST isn't edited, it's the input and shouldn't change during a request as the request input doesn't change during a request - that's just logically wrong.
If you want the values as they're returned by validation use $val->validated('username') - check out the examples in the docs.
And as far as Sessions are concerned, the docs explain exactly how you should use them.
It is not their job to inform them how NOT to use them. The fact that you link any session functionality to an array called $_SESSION is something we can't do anything about.
Note that most frameworks don't use $_SESSION, it's an outdated PHP4 concept, and not very secure if combined by PHP's native session handling...
@WanWizard The documentation is great and much appreciated. I understand the security issues and the assumption was my fault. A simple note added to the docs such as "The Session Class does not rely on PHP's $_SESSION" would suffice and might save some debugging time for those new to using frameworks or those trying to port older code.
Donate
